>: If I have a static global variable ( which goes into BSS area of the
>: process or vxWorks image ) does not get initialized to '0' for the mips
>: (R4000) target compilation/linking!
>: on VxSim (simulator on Windows NT) 'else_condition_code_block'
>: gets executed, where as on mips target 'if_condition_code_block'
>: gets executed!
>Yes, that is what you get when you use uninitialised memory: The BSS
>segment is prabably initialised on startup of your system, but this is a
>configuration item. But when you use an area that already was used by
>another module the area will contain random data.
But the BSS segment is something that belongs to each individual
executable file, and each one _should_ be cleared when it is loaded by
ld. Obviously if he's running the program from the command shell, the
second time he runs it the variables in the BSS section will still have
the same values from the last run, but nothing he said suggested that
Quote:>If you want predictable results NEVER use uninitialised data!
This was my first reaction, but then I double-checked. It's only automatic
variables that don't get cleared. Static file-scope variables should be
initialized to zero, according to the C language spec. This is an excerpt
from the comp.lang.c FAQ, available at
1.30: What am I allowed to assume about the initial values
of variables which are not explicitly initialized?
If global variables start out as "zero", is that good
enough for null pointers and floating-point zeroes?
A: Uninitialized variables with "static" duration (that is, those
declared outside of functions, and those declared with the
storage class static), are guaranteed to start out as zero, as
if the programmer had typed "= 0". Therefore, such variables
are implicitly initialized to the null pointer (of the correct
type; see also section 5) if they are pointers, and to 0.0 if
they are floating-point.
Variables with "automatic" duration (i.e. local variables
without the static storage class) start out containing garbage,
unless they are explicitly initialized. (Nothing useful can be
predicted about the garbage.)
Dynamically-allocated memory obtained with malloc() and
realloc() is also likely to contain garbage, and must be
initialized by the calling program, as appropriate. Memory
obtained with calloc() is all-bits-0, but this is not
necessarily useful for pointer or floating-point values (see
question 7.31, and section 5).
References: K&R1 Sec. 4.9 pp. 82-4; K&R2 Sec. 4.9 pp. 85-86; ISO
Sec. 6.5.7, Sec. 188.8.131.52, Sec. 184.108.40.206; H&S Sec. 4.2.8 pp. 72-
3, Sec. 4.6 pp. 92-3, Sec. 4.6.2 pp. 94-5, Sec. 4.6.3 p. 96,
Sec. 16.1 p. 386.
So it looks like there's a problem with the MIPS version of ld(...).
I wouldn't recommend sex, * or insanity for everyone, but they've
always worked for me.
-- Hunter S. Thompson