[edit] alignment ?

"If allocation succeeds, returns a pointer to the lowest (first) byte in the allocated memory block that is suitably aligned for any object type."

For C11, where does the standard claim any alignment requirements for the malloc - function? 129.247.31.224 06:23, 22 August 2018 (PDT)

http://port70.net/~nsz/c/c11/n1570.html#7.22.3p1 --Cubbi (talk) 06:34, 22 August 2018 (PDT)

Yes, well, if you refer to section "7.22.3.4 The malloc function", all it says is

"Description

2 The malloc function allocates space for an object whose size is specified by size and whose value is indeterminate.

Returns

3 The malloc function returns either a null pointer or a pointer to the allocated space. "

No statement that the memory returned has to be aligned in any way, is there? Do I get something wrong? Widarr (talk) 07:00, 22 August 2018 (PDT)

Ah, I see, should have read the introduction to that section as well ... Thanks for clarification! Widarr (talk) 07:02, 22 August 2018 (PDT)

right, that's one of the reasons this reference exists - specifications that apply simultaneously may be a hundred pages apart in the text of the standard. --Cubbi (talk) 07:22, 22 August 2018 (PDT)

[edit] Question

According to C standard malloc returns a pointer which is suitably aligned for any object with fundamental alignment. This means that the returned pointer has alignment of at least alignof(max_align_t).

But is it possible for malloc to return a pointer with alignment greater than alignof(max_align_t)? (削除) If we assume that caller is allowed to use the returned pointer in all contexts then that should not be possible as alignments greater than alignof(max_align_t) are only supported in some specific contexts. (削除ここまで) --PersianCat (talk) 02:21, 23 June 2022 (PDT)

Sounds like you're concerned about the complexities of over-aligned types? malloc doesn't deal in types, so the possibly-greater-than-strictly-necessary alignment of the address returned by malloc is inconsequential --Ybab321 (talk) 03:17, 23 June 2022 (PDT)

My mistake was that I misinterpreted 6.2.8.3 in the standard to mean that it is implementation-defined where the objects with extended alignments can be used. The statement means that it is implementation-defined where the extended alignments themselves can be used. For example an implementation may support an specific extended alignment only in aligned_alloc and not in _Alignas.

So malloc may actually return a pointer with alignment more than alignof(max_align_t)? For example if alignof(max_align_t) equals 8 then is it possible for the returned pointer to be multiple of 16?

Also I just saw that aligned_alloc page states:

"Regular malloc aligns memory suitable for any object type (which, in practice, means that it is aligned to alignof(max_align_t))."

--PersianCat (talk) 06:50, 23 June 2022 (PDT)

Yeah I don't see any reason why malloc wouldn't be aligned to a multiple of 16 or some such. If malloc only ever returned address 0x10000000 and nullptr on all other calls, that would be a valid implementation that's 0x10000000-aligned --Ybab321 (talk) 08:34, 23 June 2022 (PDT)

Thank you for clarifying. That makes sense. --PersianCat (talk) 09:02, 23 June 2022 (PDT)

[edit] Uninitialized or indeterminate

Does C standard mandates that malloc should not initialize allocated memory?

According to clause 7.22.3.4 of the standard, the content of allocated memory is Indeterminate. According to clause 3.19.2 Indeterminate either means unspecified or trap representation. Many implementations don't have trap representation and thus the content of allocated memory would be unspecified in such implementations. An implementation might actually choose and document unspecified values. So an implementation should be able to initialize malloced memory and document it.

The second answer of this Stackoverflow question, also says that it is implementation-defined whether malloc initializes allocated memory or not.

Thus I believe "uninitialized" should be changed to "indeterminate". --PersianCat (talk) 15:31, 23 June 2022 (PDT)

yes the value of the allocated object is indeterminate in the spec, as you quoted, with the primary consequence that reading that value is undefined behavior J.2, where the C standard enumerates undefined behaviors, "The value of the object allocated by the malloc function is used"). Although analysis on this SO answer disagrees that it is actually undefined (unlike reading an uninitialized automatic variable whose address was never taken, which is undefined in the main text of the standard, not in the J appendix). Yes, a libc runtime can document that e.g. in debug mode, MSVC malloc fills the pages with 0xCDCDCDCD, but a C program that reads that value is still (maybe?) undefined. We can definitely add a note mentioning 0xCDCDCDCD, come to think of it - it's something programmers actually encounter and we want to serve programmers more than language lawyers. --Cubbi (talk) 17:32, 23 June 2022 (PDT)

Well I first saw this possibility in page 152 of 2nd Edition of Secure Coding in C and C++. But after seeing that rule EXP33-C of SEI CERT C Coding Standard also assumes that indeterminate in this context also means uninitialized I think there is no need for change.--PersianCat (talk) 23:12, 23 June 2022 (PDT)