Am Do., 22. Aug. 2024 um 07:27 Uhr schrieb Paul Eggert <egg...@cs.ucla.edu>:
> 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.
Marc
> 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.
>
>
