Bug in gcc4 initialisers suspected

  • Thread starter Marcel van Kervinck
  • Start date
M

Marcel van Kervinck

Dear all,

I would like to confirm my suspicion of a compiler
bug in gcc4 for MacOSX. The code example below expects
that the initializer of 'v' sets all elements in
v.u.bytes[] to zero, as specified by the C99 standard:

"""21 If there are fewer initializers in a brace-enclosed
list than there are elements or members of an
aggregate, [...] the remainder of the aggregate shall
be initialized implicitly the same as objects that
have static storage duration."""
(ref: ANSI+ISO+IEC+8999-1999, 6.7.8 Initialization, p.127)

However, the code only works as expected on some platforms:

system cpu compiler result
------ --- -------- ------
SunOS-5.8 UltraSPARC-IIe gcc-2.95.3 returns OK
FreeBSD-4.11 Pentium2 gcc-2.95.4 returns OK
SunOS-5.8 UltraSPARC-IIi gcc-3.1.1 returns OK
Darwin-7.9.0 PowerPC-G4 gcc-3.3 returns OK
Linux-2.4.29 Celeron gcc-3.3.5 returns OK
FreeBSD-5.4 Pentium4 gcc-3.4.2 returns OK
Darwin-8.0.0 PowerPC-G4 gcc-4.0.0 failed assertion `v.u.bytes[1] == 0'
Darwin-8.0.0 PowerPC-G5 gcc-4.0.0 failed assertion `v.u.bytes[1] == 0'

Interestingly, removing the intermediate
level 'union u' makes the code pass.

The questions I'm seeking an answer to:
1. Is this a compiler bug or a display of undefined behaviour?
2. Is this gcc4-specific or only in combination with PowerPC?

Best regards,

Marcel
-- _ _
_| |_|_|
|_ |_ Marcel van Kervinck
|_| (e-mail address removed)

----------------------------------------------------------------
#include <assert.h>

typedef struct {
union {
unsigned char bytes[2];
} u;
} vector_t;

int main(void)
{
int i;
for (i=0; i<2; i++) {
vector_t v = {{{0,}}};
assert(v.u.bytes[1] == 0);
v.u.bytes[1]++;
}
}
----------------------------------------------------------------
 
M

Michael Mair

Marcel said:
Dear all,

I would like to confirm my suspicion of a compiler
bug in gcc4 for MacOSX. The code example below expects
that the initializer of 'v' sets all elements in
v.u.bytes[] to zero, as specified by the C99 standard:

"""21 If there are fewer initializers in a brace-enclosed
list than there are elements or members of an
aggregate, [...] the remainder of the aggregate shall
be initialized implicitly the same as objects that
have static storage duration."""
(ref: ANSI+ISO+IEC+8999-1999, 6.7.8 Initialization, p.127)

However, the code only works as expected on some platforms:

system cpu compiler result
------ --- -------- ------
SunOS-5.8 UltraSPARC-IIe gcc-2.95.3 returns OK
FreeBSD-4.11 Pentium2 gcc-2.95.4 returns OK
SunOS-5.8 UltraSPARC-IIi gcc-3.1.1 returns OK
Darwin-7.9.0 PowerPC-G4 gcc-3.3 returns OK
Linux-2.4.29 Celeron gcc-3.3.5 returns OK
FreeBSD-5.4 Pentium4 gcc-3.4.2 returns OK
Darwin-8.0.0 PowerPC-G4 gcc-4.0.0 failed assertion `v.u.bytes[1] == 0'
Darwin-8.0.0 PowerPC-G5 gcc-4.0.0 failed assertion `v.u.bytes[1] == 0'

Interestingly, removing the intermediate
level 'union u' makes the code pass.

The questions I'm seeking an answer to:
1. Is this a compiler bug or a display of undefined behaviour?
2. Is this gcc4-specific or only in combination with PowerPC?

The problem is that without your telling us how you invoke gcc,
we cannot tell.
Did you compile with "-std=c99 -pedantic"?
Did you check gcc.gnu.org/c99status.html?

Apart from that, gnu.gcc.help may be a better place to ask.

Cheers
Michael
Best regards,

Marcel
-- _ _
_| |_|_|
|_ |_ Marcel van Kervinck
|_| (e-mail address removed)

----------------------------------------------------------------
#include <assert.h>

typedef struct {
union {
unsigned char bytes[2];
} u;
} vector_t;

int main(void)
{
int i;
for (i=0; i<2; i++) {
vector_t v = {{{0,}}};
assert(v.u.bytes[1] == 0);
v.u.bytes[1]++;
}
}
----------------------------------------------------------------
 
S

S.Tobias

In comp.lang.c Michael Mair said:
Marcel van Kervinck wrote:
I would like to confirm my suspicion of a compiler
bug in gcc4 for MacOSX. The code example below expects
that the initializer of 'v' sets all elements in
v.u.bytes[] to zero, as specified by the C99 standard:
[snip]
Darwin-8.0.0 PowerPC-G4 gcc-4.0.0 failed assertion `v.u.bytes[1] == 0'
Darwin-8.0.0 PowerPC-G5 gcc-4.0.0 failed assertion `v.u.bytes[1] == 0'

Interestingly, removing the intermediate
level 'union u' makes the code pass.

The questions I'm seeking an answer to:
1. Is this a compiler bug or a display of undefined behaviour?
2. Is this gcc4-specific or only in combination with PowerPC?
The problem is that without your telling us how you invoke gcc,
we cannot tell.
Did you compile with "-std=c99 -pedantic"?
Did you check gcc.gnu.org/c99status.html?

I don't see anything in the code which is C99 specific.

[snip]
#include <assert.h>

typedef struct {
union {
unsigned char bytes[2];
} u;
} vector_t;

int main(void)
{
int i;
for (i=0; i<2; i++) {
vector_t v = {{{0,}}};
assert(v.u.bytes[1] == 0);
v.u.bytes[1]++;
}
}

If the `assert' fails, then it's most probably a compiler bug.
But I am not an authority here (writing from clc).
 
M

Michael Mair

S.Tobias said:
In comp.lang.c Michael Mair said:
Marcel van Kervinck wrote:
I would like to confirm my suspicion of a compiler
bug in gcc4 for MacOSX. The code example below expects
that the initializer of 'v' sets all elements in
v.u.bytes[] to zero, as specified by the C99 standard:
[snip]

Darwin-8.0.0 PowerPC-G4 gcc-4.0.0 failed assertion `v.u.bytes[1] == 0'
Darwin-8.0.0 PowerPC-G5 gcc-4.0.0 failed assertion `v.u.bytes[1] == 0'

Interestingly, removing the intermediate
level 'union u' makes the code pass.

The questions I'm seeking an answer to:
1. Is this a compiler bug or a display of undefined behaviour?
2. Is this gcc4-specific or only in combination with PowerPC?

The problem is that without your telling us how you invoke gcc,
we cannot tell.
Did you compile with "-std=c99 -pedantic"?
Did you check gcc.gnu.org/c99status.html?


I don't see anything in the code which is C99 specific.

C89 requires either a return statement in main() or another
way of not running into the end of main() (e.g. exit() or
abort()). C99 allows you to fall off the end of main()...

So, given a "return 0;", the code could also be compiled with
"-std=c89 -pedantic" (or equivalently with "-ansi -pedantic"

Cheers
Michael
[snip]

#include <assert.h>

typedef struct {
union {
unsigned char bytes[2];
} u;
} vector_t;

int main(void)
{
int i;
for (i=0; i<2; i++) {
vector_t v = {{{0,}}};
assert(v.u.bytes[1] == 0);
v.u.bytes[1]++;
}
}


If the `assert' fails, then it's most probably a compiler bug.
But I am not an authority here (writing from clc).
 
M

Marcel van Kervinck

In comp.std.c Michael Mair said:
S.Tobias said:
In comp.lang.c Michael Mair said:
Marcel van Kervinck wrote:

I would like to confirm my suspicion of a compiler
bug in gcc4 for MacOSX. The code example below expects
that the initializer of 'v' sets all elements in
v.u.bytes[] to zero, as specified by the C99 standard:
[snip]


Darwin-8.0.0 PowerPC-G4 gcc-4.0.0 failed assertion `v.u.bytes[1] == 0'
Darwin-8.0.0 PowerPC-G5 gcc-4.0.0 failed assertion `v.u.bytes[1] == 0'

Interestingly, removing the intermediate
level 'union u' makes the code pass.

The questions I'm seeking an answer to:
1. Is this a compiler bug or a display of undefined behaviour?
2. Is this gcc4-specific or only in combination with PowerPC?

The problem is that without your telling us how you invoke gcc,
we cannot tell.
Did you compile with "-std=c99 -pedantic"?
Did you check gcc.gnu.org/c99status.html?


I don't see anything in the code which is C99 specific.
C89 requires either a return statement in main() or another
way of not running into the end of main() (e.g. exit() or
abort()). C99 allows you to fall off the end of main()...
So, given a "return 0;", the code could also be compiled with
"-std=c89 -pedantic" (or equivalently with "-ansi -pedantic"

Thanks for your response,

Please don't divert from the question, which is about the
failing assert on the initialized value.

The compiler settings are mostly irrelevant for reproducing,
but a good example would be simply gcc -o bug bug.c

C99 doesn't require an explicit return from the initial
invokation of main, as explained in page 13 of the standard:
"""reaching the } that terminates the
main function returns a value of 0"""

Thanks,

Marcel
#include <assert.h>

typedef struct {
union {
unsigned char bytes[2];
} u;
} vector_t;

int main(void)
{
int i;
for (i=0; i<2; i++) {
vector_t v = {{{0,}}};
assert(v.u.bytes[1] == 0);
v.u.bytes[1]++;
}
}


If the `assert' fails, then it's most probably a compiler bug.
But I am not an authority here (writing from clc).
 
M

Michael Mair

Marcel said:
In comp.std.c Michael Mair said:
S.Tobias said:
Marcel van Kervinck wrote:


I would like to confirm my suspicion of a compiler
bug in gcc4 for MacOSX. The code example below expects
that the initializer of 'v' sets all elements in
v.u.bytes[] to zero, as specified by the C99 standard:

[snip]



Darwin-8.0.0 PowerPC-G4 gcc-4.0.0 failed assertion `v.u.bytes[1] == 0'
Darwin-8.0.0 PowerPC-G5 gcc-4.0.0 failed assertion `v.u.bytes[1] == 0'

Interestingly, removing the intermediate
level 'union u' makes the code pass.

The questions I'm seeking an answer to:
1. Is this a compiler bug or a display of undefined behaviour?
2. Is this gcc4-specific or only in combination with PowerPC?


The problem is that without your telling us how you invoke gcc,
we cannot tell.
Did you compile with "-std=c99 -pedantic"?
Did you check gcc.gnu.org/c99status.html?


I don't see anything in the code which is C99 specific.

C89 requires either a return statement in main() or another
way of not running into the end of main() (e.g. exit() or
abort()). C99 allows you to fall off the end of main()...

So, given a "return 0;", the code could also be compiled with
"-std=c89 -pedantic" (or equivalently with "-ansi -pedantic"


Thanks for your response,

Please don't divert from the question, which is about the
failing assert on the initialized value.

The compiler settings are mostly irrelevant for reproducing,
but a good example would be simply gcc -o bug bug.c

This is wrong.
gcc has the default setting "-std=gnu89" which is neither C89
nor C99 and may do as GNU wants.
So, unless you can confirm that you compiled in C89 mode or the
C99-like mode _including_ "-pedantic", there is nothing to be
added.
If you compiled with what C99 you can get from gcc and the
C99 status page does not report some sort of error at
initialisation, then you have a bug. Otherwise, there may be
just some unspecified behaviour w.r.t. the GNU standard,
which in the case of your platform might be specified
just the other way round.
So, please, just _answer_ the two questions given above,
either for yourself, or here.
Once more: gnu.gcc.help may be a better place to ask.

Cheers
Michael
C99 doesn't require an explicit return from the initial
invokation of main, as explained in page 13 of the standard:
"""reaching the } that terminates the
main function returns a value of 0"""

Thanks,

Marcel

#include <assert.h>

typedef struct {
union {
unsigned char bytes[2];
} u;
} vector_t;

int main(void)
{
int i;
for (i=0; i<2; i++) {
vector_t v = {{{0,}}};
assert(v.u.bytes[1] == 0);
v.u.bytes[1]++;
}
}


If the `assert' fails, then it's most probably a compiler bug.
But I am not an authority here (writing from clc).
 
J

jacob navia

Using the lcc-win32 compiler, the code works without any assertion failure
Using gcc-2.96 it works too
Using gcc 3.34it works.

So, it looks like a bug in that version of gcc
 
R

Randy Howard

Using the lcc-win32 compiler, the code works without any assertion failure
Using gcc-2.96 it works too
Using gcc 3.34it works.

So, it looks like a bug in that version of gcc

I just tried in on 10.4.1 Tiger w/gcc 4.0.0.
Using -std=c99 -pedantic it fails.
Adding return 0; and changing to -std=c89 also fails.

Is should be taken up with the gcc maintainers.
 
F

Flash Gordon

jacob said:
Using the lcc-win32 compiler, the code works without any assertion failure
Using gcc-2.96 it works too
Using gcc 3.34it works.

So, it looks like a bug in that version of gcc

Jacob, you have been around here long enough to know to quote sufficient
of the message you are replying to for people to see what you are
replying to. I don't know about Thunderbird 0.9 (though I would be
surprised if it was different), but the current version certainly helps
in this by quoting the material for you by default.
 
S

S.Tobias

I don't agree. In C89 you could "safely" fall-off the initial
`main', it's the termination status that was undefined (or,
perhaps, better to say "unspecified"), not the behaviour.


He was merely replying to my remark, giving me a hint that
I might have missed. His answer was justified.
And diversions are one of the main features of clc, ISTM.

BTW, I compiled your program with como (both in C89 and C99 mode)
and had no warnings or failed assertions.
Once more: gnu.gcc.help may be a better place to ask.

I think so too.

Not in C89, this appeared in C99.
 
J

jacob navia

Flash said:
Jacob, you have been around here long enough to know to quote sufficient
of the message you are replying to for people to see what you are
replying to. I don't know about Thunderbird 0.9 (though I would be
surprised if it was different), but the current version certainly helps
in this by quoting the material for you by default.
Excuse me, I deleted the quote to make the message more concise and
avoid repeating. Bad idea.

I was answering to this thread:
Bug in gcc4 initialisers suspected

Dear all,

I would like to confirm my suspicion of a compiler
bug in gcc4 for MacOSX. The code example below expects
that the initializer of 'v' sets all elements in
v.u.bytes[] to zero, as specified by the C99 standard:

"""21 If there are fewer initializers in a brace-enclosed
list than there are elements or members of an
aggregate, [...] the remainder of the aggregate shall
be initialized implicitly the same as objects that
have static storage duration."""
(ref: ANSI+ISO+IEC+8999-1999, 6.7.8 Initialization, p.127)

However, the code only works as expected on some platforms:

system cpu compiler result
------ --- -------- ------
SunOS-5.8 UltraSPARC-IIe gcc-2.95.3 returns OK
FreeBSD-4.11 Pentium2 gcc-2.95.4 returns OK
SunOS-5.8 UltraSPARC-IIi gcc-3.1.1 returns OK
Darwin-7.9.0 PowerPC-G4 gcc-3.3 returns OK
Linux-2.4.29 Celeron gcc-3.3.5 returns OK
FreeBSD-5.4 Pentium4 gcc-3.4.2 returns OK
Darwin-8.0.0 PowerPC-G4 gcc-4.0.0 failed assertion `v.u.bytes[1]
== 0'
Darwin-8.0.0 PowerPC-G5 gcc-4.0.0 failed assertion `v.u.bytes[1]
== 0'

Interestingly, removing the intermediate
level 'union u' makes the code pass.

The questions I'm seeking an answer to:
1. Is this a compiler bug or a display of undefined behaviour?
2. Is this gcc4-specific or only in combination with PowerPC?

Best regards,

Marcel
-- _ _
_| |_|_|
|_ |_ Marcel van Kervinck
|_| (e-mail address removed)

----------------------------------------------------------------
#include <assert.h>

typedef struct {
union {
unsigned char bytes[2];
} u;
} vector_t;

int main(void)
{
int i;
for (i=0; i<2; i++) {
vector_t v = {{{0,}}};
assert(v.u.bytes[1] == 0);
v.u.bytes[1]++;
}
}
----------------------------------------------------------------
 
K

kuyper

Marcel van Kervinck wrote:
....
The compiler settings are mostly irrelevant for reproducing,
but a good example would be simply gcc -o bug bug.c

The compiler settings are not irrelevant; whether or not this behavior
is a bug or a feature depends upon what standard it's being compared
against. With the options you've chosen, gcc makes no claims to conform
to any version of the C standard. The only thing that's relevant to the
question of whether the behavior is a bug or a feature is the
documentation of gcc itself, and the question is off-topic for a group

Your question can only be on-topic for this group if it the C standard
is relevant. That requires that you use the set of options that are
supposed to make gcc conform to the C standard (-std=C99 -pedantic).
C99 doesn't require an explicit return from the initial
invokation of main, as explained in page 13 of the standard:
"""reaching the } that terminates the
main function returns a value of 0"""

With the compiler options you've chose, what C99 requires is
irrelevant.

If you use the compiler options that make C99 the relevant standard,
and you still get assertion failures, then the compiler is failing to
conform to a standard its creators say its supposed to conform to, and
you should therefore file a bug report. If you can only reproduce the
problem in non-conforming mode, then you should check with the gcc
documentation to find out what is promised when using that set of
options.
 
M

Marcel van Kervinck

In said:
If you use the compiler options that make C99 the relevant standard,
and you still get assertion failures, then the compiler is failing to
conform to a standard its creators say its supposed to conform to, and
you should therefore file a bug report.

Thank you very much,

The reason I cross-posted to comp.std.c is precisely because I
was wondering if I'd missed something in the standard that can
be an excuse for the failing assert. (Like a mis-interpretation
of 'aggregate' or missing some rules for unions.) This doesn't
seem to be the case, so I'll consider it a compiler bug now.

The program is failing with any gcc4 settings, including the
ones suggested by various posters (except -DNDEBUG=1, for the
hair-splitters :) That is what I intended to say with
'irrelevant': the settings really don't make a difference so
I didn't like to be overspecific. I didn't want to say it is
unimportant to try. It is and I did. The outcome is that it
doesn't matter, so we can forget about it as a factor: It was
going to be either a bug in the compiler or in the program.
Given its nature (basic initalisation) it ought to be fixed
both in gcc-mode and in C99 mode.

I'ld like to express my thanks to the many people who had the
flexibility of mind to look through any ambiguity and made
an actual effort to look at the little program and the standard.
And also to those who took the time to test their compiler for
it, using any settings that they regarded as relevant, before
sharing their opinion.

A bug report is filed with both the vendor and the gcc team.

Follow-ups are best directed to the gnu groups.

Best regards,

Marcel
-- _ _
_| |_|_|
|_ |_ Marcel van Kervinck
|_| (e-mail address removed)
 
K

Keith Thompson

Michael Mair said:
[...]

Thank you, I did not know that (in fact, the compilers I am usually
working with complain -- directly or indirectly -- about the missing
return statement when forced into standard mode).
Is this the consensus of comp.std.c or just an interpretation of the
scripture?

C90 5.1.2.2.3:

A return from the initial call to the main function is equivalent
to calling the exit function with the value returned by the main
function as its argument. If the main function executes a return
that specifies no value, the termination status returned to the
host environment is undefined.

C90 6.6.6.4:

Reaching the } that terminates a function is equivalent to
executing a return statement without an expression.

C99 5.1.2.2.3:

If the return type of the main function is a type compatible with
int, a return from the initial call to the main function is
equivalent to calling the exit function with the value returned by
the main function as its argument; reaching the } that
terminates the main function returns a value of 0. If the return
type is not compatible with int, the termination status returned
to the host environment is unspecified.

Nevertheless, compilers are allowed to complain (issue diagnostics)
even when the behavior is well-defined.
 
M

Michael Mair

Keith said:
Michael Mair said:
S.Tobias said:
I don't agree. In C89 you could "safely" fall-off the initial
`main', it's the termination status that was undefined (or,
perhaps, better to say "unspecified"), not the behaviour.
[...]

Thank you, I did not know that (in fact, the compilers I am usually
working with complain -- directly or indirectly -- about the missing
return statement when forced into standard mode).
Is this the consensus of comp.std.c or just an interpretation of the
scripture?


C90 5.1.2.2.3:

A return from the initial call to the main function is equivalent
to calling the exit function with the value returned by the main
function as its argument. If the main function executes a return
that specifies no value, the termination status returned to the
host environment is undefined.

C90 6.6.6.4:

Reaching the } that terminates a function is equivalent to
executing a return statement without an expression.

C99 5.1.2.2.3:

If the return type of the main function is a type compatible with
int, a return from the initial call to the main function is
equivalent to calling the exit function with the value returned by
the main function as its argument; reaching the } that
terminates the main function returns a value of 0. If the return
type is not compatible with int, the termination status returned
to the host environment is unspecified.

Nevertheless, compilers are allowed to complain (issue diagnostics)
even when the behavior is well-defined.

Thank you very much :)

Cheers
Michael
 
P

Peter Shaggy Haywood

Groovy hepcat Marcel van Kervinck was jivin' on 17 May 2005 15:37:00
GMT in comp.lang.c.
Bug in gcc4 initialisers suspected's a cool scene! Dig it!
I would like to confirm my suspicion of a compiler
bug in gcc4 for MacOSX. The code example below expects
that the initializer of 'v' sets all elements in
v.u.bytes[] to zero, as specified by the C99 standard:

"""21 If there are fewer initializers in a brace-enclosed
list than there are elements or members of an
aggregate, [...] the remainder of the aggregate shall
be initialized implicitly the same as objects that
have static storage duration."""
(ref: ANSI+ISO+IEC+8999-1999, 6.7.8 Initialization, p.127)

However, the code only works as expected on some platforms:

(Code moved here into the body of the post from the OP's sig block.
It's not a good idea to put the code in your sig block.)
#include <assert.h>

typedef struct {
union {
unsigned char bytes[2];
} u;
} vector_t;

int main(void)
{
int i;
for (i=0; i<2; i++) {
vector_t v = {{{0,}}};
assert(v.u.bytes[1] == 0);
v.u.bytes[1]++;
}
}
system cpu compiler result
------ --- -------- ------
SunOS-5.8 UltraSPARC-IIe gcc-2.95.3 returns OK
FreeBSD-4.11 Pentium2 gcc-2.95.4 returns OK
SunOS-5.8 UltraSPARC-IIi gcc-3.1.1 returns OK
Darwin-7.9.0 PowerPC-G4 gcc-3.3 returns OK
Linux-2.4.29 Celeron gcc-3.3.5 returns OK
FreeBSD-5.4 Pentium4 gcc-3.4.2 returns OK
Darwin-8.0.0 PowerPC-G4 gcc-4.0.0 failed assertion `v.u.bytes[1] == 0'
Darwin-8.0.0 PowerPC-G5 gcc-4.0.0 failed assertion `v.u.bytes[1] == 0'

Interestingly, removing the intermediate
level 'union u' makes the code pass.

That's odd. Are you sure the compiler is handling the union
correctly? Try printing sizeof v.u and seeing whether this is what you
expect. Maybe the array is being treated as two union members instead
of one. If so, then it's a bug. Or maybe I'm way off base here.
The questions I'm seeking an answer to:
1. Is this a compiler bug or a display of undefined behaviour?

Looks like a bug to me. But there may have been some nuance I've
missed that makes this legal. I can't say for sure.
2. Is this gcc4-specific or only in combination with PowerPC?

I don't know. I don't have gcc4 or a PowerPC, so I can't test it
here.

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?
 
P

Peter Shaggy Haywood

Groovy hepcat Marcel van Kervinck was jivin' on 18 May 2005 02:23:11
GMT in comp.lang.c.
Re: Bug in gcc4 initialisers suspected's a cool scene! Dig it!
In comp.std.c Michael Mair said:
S.Tobias said:
Marcel van Kervinck wrote:

I would like to confirm my suspicion of a compiler
bug in gcc4 for MacOSX. The code example below expects
that the initializer of 'v' sets all elements in
v.u.bytes[] to zero, as specified by the C99 standard:

The problem is that without your telling us how you invoke gcc,
we cannot tell.
Did you compile with "-std=c99 -pedantic"?
Did you check gcc.gnu.org/c99status.html?

I don't see anything in the code which is C99 specific.
C89 requires either a return statement in main() or another
way of not running into the end of main() (e.g. exit() or
abort()). C99 allows you to fall off the end of main()...
So, given a "return 0;", the code could also be compiled with
"-std=c89 -pedantic" (or equivalently with "-ansi -pedantic"

The compiler settings are mostly irrelevant for reproducing,

They're not irrelevant here. We need to know that the compiler was
invoked in the strictest standard conforming mode.
but a good example would be simply gcc -o bug bug.c

Then you may be seeing behaviour relying on some kind of obscure
extention or something. Who knows? Invoke the compiler with -std=c99
-pedantic or -ansi -pedantic, as Michael already suggested, and then
tell us what happens.

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?
 
G

glen herrmannsfeldt

Marcel said:
Dear all,

I would like to confirm my suspicion of a compiler
bug in gcc4 for MacOSX. The code example below expects
that the initializer of 'v' sets all elements in
v.u.bytes[] to zero, as specified by the C99 standard:
(snip)

typedef struct {
union {
unsigned char bytes[2];
} u;
} vector_t;

It seems that none of the posts so far have mentioned the union.

As I understand, though I could be wrong, the standard sets the
value of the variable to zero, not just bytes. (The distinction
is important when using memset()).

As some variable types might have non-zero bit representation when
the value is zero, and a union could have more than one type of
variable, it seems slightly possible that the restriction is lifted
for unions. I might even wonder about using initializers when you
can't specify which of the union variables is being initialized.

Still, on most machines float, double, and pointers should initialize
with all bits zero, and most systems do just that.

Consider:

typedef struct {
union {
double d;
unsigned char bytes[2];
} u;
} vector_t;

int main(void)
{
int i;
for (i=0; i<2; i++) {
vector_t v = {{{1}}};
assert(v.u.bytes[0] == 1);
v.u.bytes[1]++;
}
}

-- glen
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top