🚀 go-pugleaf

>>>>> If you malloc, say, 3 bytes, malloc is not required to provide alignment
>>>>> for a 4-byte object, say an int.
>>>> It is funny. Last time this question came up, someone posted that the
>>>> committee believes that malloc result is always aligned for everything!
>>> I asked this in a Defect Report. The response is still in balloting, but
>>> will almost certainly be that it must be correctly aligned.
>> It is unclear to me why a defect report is needed here. Will the ruling
>> affect any strictly conforming (or even any "strongly conforming") program?

>By simple logic, it could do so only if it (a) amends the standard or
>(b) is incorrect.

I agree.  However, there seems to be no correlation among (a) the clarity
of any particular part of the standard, (b) the submission of a defect
report, and (c) the ruling (choose any two or three).

>The ruling will *determine whether* the technique mentioned a few articles
>back in the thread, of implementing a variable length struct by malloc()ing
>an object of size less than what sizeof returns for the struct, can occur
>in a strictly conforming program.

I disagree.  The cited defect report asks only about malloc.  Even if the
ruling upholds the standard's wording on aligned results, it's hard to
imagine that it will discard requirements on compatibility, etc.

If an object is actually smaller than what sizeof returns for the type,
then a strictly conforming program cannot try to use that type to access
the object.  (The standard also prohibits this fudging between int and
long -- even when they happen to have the same size and alignment
requirements -- and between incompatible function pointer types.)
--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer