Re: Uninitialised fields in structures



vippstar@xxxxxxxxx wrote:
On Dec 31, 12:58 pm, Ulrich Eckhardt <dooms...@xxxxxxxx> wrote:
[Not explicitly initialised fields of a struct that is partially
initialised are implicitly initialised to zero. ]
Now, I'm pretty sure about the rule with the additional fields, but I'm
wondering nonetheless. Can someone confirm or deny whether t.len above is
initialised or not?
The standard doesn't say anything about initializing the rest members
to 0.

Well, that's where a few others and I disagree with you. Also, the compiler
only warns but still does the initialisation.

Using gdb to determine whether a program is correct or not is bad
practise, as it is to run the program and come to a conclusion by the
output. Gdb is not a 'C99 tool'.

Well, surely it is not a way to prove that the program is correct C.
However, I have four different opinions on whether the program is buggy:

1. Compiler
The compiler said something was uninitialised, which often causes errant
runtime behaviour, in my case it would have lead to calling free() with a
pointer to a string literal. Of course that is not a proof, since
uninitialised storage can contain anything, including a very deterministic
value.

2. Running
Running the program didn't cause any runtime errors, as free()ing a string
literal usually does. Same uncertainty as above though, but glibc otherwise
correctly detects this error.

3. Valgrind
Typically valgrind doesn't care too much about C but operates directly on
the generated machine code. The fact that it detects use of uninitialised
memory was what first prompted me to wonder whether there was something
behind the warnings emitted by the compiler.

4. GDB (a debugger)
I used the debugger to manually shred the memory of the variable that was
claimed to be not initialised. I observed that code was executed to lateron
initialise the variable to zero.

I'm aware that none of these tests are in any way mandated by any C
standard, but that's real life. ;)


Just for the interest of those that are reading this: the actual problem was
with my use of Valgrind. If I had paid a bit more attention to its output,
I would have seen that the errors are in fact detected in /lib/ld-2.3.6.so
and not in my executable. Actually using an uninitialised struct in my code
also causes it to be detected and reported as occurring in my code, so the
compiler output can be taken as "just a [stupid] warning".

Uli

.



Relevant Pages

  • Re: PL/I, COBOL, Advantages, Equivalence, et al
    ... on initializing scalar variables helps prevent some defects, ... The Ada Safety and Security ... "The pragma Normalize_Scalars directs the compiler to initialize otherwise uninitialized scalar variables with predictable values. ...
    (comp.lang.pl1)
  • Re: Typedef in C#?
    ... >>> infer the type for the variable from the value of the initializing ... > No, it's not like that - the compiler will know the exact type, and ... ListGetIt() ... iterators - "If it has the methods of an iterator it can be used as an ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Status of a 2.6.30 kernel ? Other sources for a 2.6.30 kernel.
    ... although GCC would seem broken if it really generates the code claimed, initializing a variable does not prevent it from being NULL. ... While optimizing the code, the compiler will ... remove the if block (the check if tun is NULL) completely from the ... BASH BUFFER OVERFLOW - if bash is being run by a ...
    (Fedora)
  • Re: Uninitialised fields in structures
    ... initialised are implicitly initialised to zero. ... The standard doesn't say anything about initializing the rest members ... Also, the compiler ... Typically valgrind doesn't care too much about C but operates directly on ...
    (comp.lang.c)
  • Re: zero values on dynamic array
    ... One might as well wonder whether there is a compiler option to make the ... variables to zero, many compilers have that. ... Initializing dynamically allocated memory to zero is also plausible. ... But initializing out-of-bounds data to zero is not compiler dependent, ...
    (comp.lang.fortran)