On 2024-08-21 06:36, Bruno Haible wrote:
> In summary, this paragraph makes no sense for structs.
Hmm, well, the paragraph makes sense to me. I suppose somebody could
fire off a question to the C committee about the intent of the paragraph.
I see how it can make sense. In Bruno's vector struct example, a compiler would be able to allocate registers for the individual struct members that are used and would not have to allocate a contiguous memory block for the entire struct.
However, see the second code block in Example 4 of section 6.7.3.1 (in the latest draft of C23). This may, of course, be itself an error as the example is about restrict and not about uninitialized structs.
In the meantime it's an engineering decision - should we port to verrry
picky implementations that complain about components of the struct not
being initialized? This is a valid question regardless of the standard's
intent.
I expect that it's not high priority to change the code, if the only
picky implementation is SAST (which I've never used and which I suspect
is chock-full of false positives anyway). If it's GCC's -fanalyzer or
sanitizer or valgrind or something else we (or at least I) commonly use,
though, that'd be a different matter.
Also, if the C committee comes back and says behavior is undefined, we
might want to make the change, if only as insurance.
> that 'return (struct ...) { initializers }'
> produces particularly good code with modern compilers)
Yeah, that's partly why I weighed in on this seemingly-obscure topic. I
like the more-functional style and wouldn't want "undefined behavior" to
get in its way.