On 2024-08-27 04:15, Marc Nieper-Wißkirchen wrote:
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.
Yes, that example sheds no light on
Am Do., 22. Aug. 2024 um 07:27 Uhr schrieb Paul Eggert :
> 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 p
Paul Eggert writes:
>> 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
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.
In the meantime it's an engineering decision - should
Paul Eggert wrote:
> > Copying and then discarding an uninitialized value of integer
> > or pointer type (i.e. not a signalling NaN (*)) is not undefined behaviour.
>
> Although that's how typical implementations behave, the C standard says
> that copying from a source variable has undefined beha
Is this patch necessary? The elements of the structure are initialized
prior to the return statement.
Since the `i`, `j`, and `count` are not really used, I feel like the SAST
report I've sent can be marked as a false positive.
Do you agree?
On Sat, Aug 17, 2024 at 7:17 AM Paul Eggert wrote:
>
On 2024-08-16 07:30, Bruno Haible wrote:
Copying and then discarding an uninitialized value of integer
or pointer type (i.e. not a signalling NaN (*)) is not undefined behaviour.
Although that's how typical implementations behave, the C standard says
that copying from a source variable has und
Hi,
Lukas Javorsky wrote:
> From my analysis, I believe that if the `GCC_LINT` or `lint` macros
> are not defined, the elements `i`, `j`, and `count` from the
> `gl_map_iterator_t` struct are not initialized
Correct.
They are not initialized because they are not used. Look at the
gl_tree_iterato
Hi,
I'm analyzing the results of SAST reports (combination of
coverity,snyk,cppcheck,gcc,clang,shellcheck,unicontrol), and from 20
findings I identified a few that might be a true positive.
However, I would like to ask you for the help to resolve it, as I'm
not 100% aware of the code internals.
