A problem initializing a static char array

[Jai Prabhu]

Hi All,

Consider the following piece of code:

void func (void)
{
static unsigned char arr[3] = "\x00\xAA\xBB";

fprintf (stderr, "0x%x\n", arr[0]);
fprintf (stderr, "0x%x\n", arr[1]);
fprintf (stderr, "0x%x\n", arr[2]);
}

On a x86 machine, with the gcc (v3.3.5) compiler, the above piece of
code (on a OpenBSD 3.8 machine) gives the following result:
[...]
0x0
0xaa
0xbb
[...]

However, with the VxWorks 5.4 C compiler (which I believe is Wind
River's) variant of gcc, the above piece of code gives the following
result (run on a x86 machine running VxWorks 5.4):

[...]
0x0
0x0
0x0
[...]

If I not use the static qualifier initializing the array, then VxWorks
host too gives the same result as OpenBSD host. Can someone explain
the discrepancy and why the VxWorks compiler would be initializing
all the elements of the array to 0x00?

TIA
Jai

 

[Keith Thompson]

Consider the following piece of code:

void func (void)
{
static unsigned char arr[3] = "\x00\xAA\xBB";

fprintf (stderr, "0x%x\n", arr[0]);
fprintf (stderr, "0x%x\n", arr[1]);
fprintf (stderr, "0x%x\n", arr[2]);
}

On a x86 machine, with the gcc (v3.3.5) compiler, the above piece of
code (on a OpenBSD 3.8 machine) gives the following result:
[...]
0x0
0xaa
0xbb
[...]

However, with the VxWorks 5.4 C compiler (which I believe is Wind
River's) variant of gcc, the above piece of code gives the following
result (run on a x86 machine running VxWorks 5.4):

[...]
0x0
0x0
0x0
[...]

If I not use the static qualifier initializing the array, then VxWorks
host too gives the same result as OpenBSD host. Can someone explain
the discrepancy and why the VxWorks compiler would be initializing
all the elements of the array to 0x00?

I can't think of any really plausible reason. It *looks* like a
compiler bug, but it's impossible to be certain of that without more
context.

Did you remember the required "#include <stdio.h>"?

As I recall, VxWorks is an embedded system, which means it's likely
that you're using a freestanding implementation. Conforming
freestanding implementations aren't required to provide most of the
standard library, including stdio; if they do provide portions of it,
it doesn't necesssarily behave as the standard describes. It's
unlikely that a variation in the behavior of fprintf would cause this
kind of problem, but it's hard to be sure.

You haven't shown us a complete program, or even a call to func(). I
can't think of anything outside the definition of func() that would
cause the symptom you're seeing (other than a malicious macro
definition for "static"), but it's hard to be sure.

If it's a system-specific issue, try asking in comp.os.vxworks.

[Hey, aioe.org is back!]

 

[Peter Nilsson]

Hi All,

Consider the following piece of code:

void func (void)
{
static unsigned char arr[3] = "\x00\xAA\xBB";

Note that "\xAA" and '\xAA' need not yield 0xAA on
non vanilla 2c implementations.

fprintf (stderr, "0x%x\n", arr[0]);
fprintf (stderr, "0x%x\n", arr[1]);
fprintf (stderr, "0x%x\n", arr[2]);

BTW, "0x%x" can be simplified to "%#x"

It wouldn't hurt to force the unsigned char's to unsigned int,
as required by %x.

}

... with the VxWorks 5.4 C compiler (which I believe is Wind
River's) variant of gcc, the above piece of code gives the
following result (run on a x86 machine running VxWorks 5.4):

[...]
0x0
0x0
0x0
[...]

If I not use the static qualifier initializing the array, then VxWorks
host too gives the same result as OpenBSD host. Can someone
explain the discrepancy and why the VxWorks compiler would
be initializing all the elements of the array to 0x00?

You should confirm that is actually the case, e.g. do a memcmp
with a zero byte initialised object. Otherwise, post a complete
compilable source that exhibits the problem.

 

[Harald van Dijk]

fprintf (stderr, "0x%x\n", arr[0]);
fprintf (stderr, "0x%x\n", arr[1]);
fprintf (stderr, "0x%x\n", arr[2]);

BTW, "0x%x" can be simplified to "%#x"

It wouldn't hurt to force the unsigned char's to unsigned int, as
required by %x.

Nor it would bring anything, no?
Aren't unsigned chars integer-promoted to unsigned int?

They are usually promoted to signed int. They are only promoted to
unsigned int when UCHAR_MAX > INT_MAX (when a conversion to signed int
might change the value), which almost certainly is not the case on your
system.