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]

Jai Prabhu <ja*******@softhome.netwrites:

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!]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Bill Leary]

"Jai Prabhu" <ja*******@softhome.netwrote in message
news:g0**********@aioe.org...

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?

VxWorks is an embedded OS and embedded tool chains often try to do
optimizations to strings, usually keyed on seeing "static" and/or a quoted
string.

So, you might also try:

static unsigned char arr[3] = { 0x00, 0xAA, 0xBB };
and/or
static unsigned char arr[3] = "\xAA\x00\xBB";

to see if perhaps you're running afoul of one of these optimizations.

- Bill

[Eric Sosman]

Jai Prabhu wrote:

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?

It looks like a compiler bug, possibly stemming from
the compiler incorrectly treating the initializer as a
string and getting confused by the leading '\0'. As an
experiment, you might want to see what happens with

static unsigned char arr[3] = "\x42\xAA\xBB";

or with

static unsigned char arr[3] = "\x42\x00\xBB";

--
Er*********@sun.com

[Peter Nilsson]

Jai Prabhu wrote:

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.

}

<snip>

... 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.

--
Peter

[Pietro Cerutti]

Peter Nilsson wrote:

Jai Prabhu wrote:

>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.

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

Peter

--
Pietro Cerutti

[Harald van =?UTF-8?b?RMSzaw==?=]

On Tue, 20 May 2008 00:07:24 +0200, Pietro Cerutti <"gahr<S P A M>gahr
wrote:

Peter Nilsson wrote:

>Jai Prabhu wrote:

>>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.