GCC-Bug ? (Unintended "overloading")

[Andreas Griesmayer]

Hi,

following piece of code causes a strange behavior when compiled with GCC
(Linux, Gentoo 3.3.5.20050130-r1). read() is called twice although only
called once, the first time before the first statement of main !
I guess there is some call to another read-function my function is wrongly
linkted to, it works fine if read() is renamed or static.
Compilation does not produce any warnings. Can anyone explain this behavior
to me or reproduce it with another compiler/operating system?

thanks,
Andreas

---------------- SNIP ---------------
#include <stdio.h>
int bit_calc(signed char bits)
{ /* do something */
}

int read(){
int value;
printf("please enter a number between -128 and 127: ");
scanf("%d",&value);
return(value);
}

int main(){
printf("start of main()\n");
signed char bits = 0;

int countbits=0;
bits=read();
//...
return 0;
}
-----------------------------------------

 

[Richard Heathfield]

Andreas Griesmayer said:

Hi,

following piece of code causes a strange behavior when compiled with GCC
(Linux, Gentoo 3.3.5.20050130-r1). read() is called twice although only
called once, the first time before the first statement of main !

read() is a system call on Linux systems. If you invoke the compiler in
conforming mode, however, there should be no clash.

Your code generates the following compiler diagnostics on my system.

foo.c:3: warning: no previous prototype for `bit_calc'
foo.c: In function `bit_calc':
foo.c:2: warning: unused parameter `bits'
foo.c:4: warning: control reaches end of non-void function
foo.c: At top level:
foo.c:6: warning: function declaration isn't a prototype
foo.c:13: warning: function declaration isn't a prototype
foo.c: In function `main':
foo.c:15: parse error before `signed'
foo.c:18: `bits' undeclared (first use in this function)
foo.c:18: (Each undeclared identifier is reported only once
foo.c:18: for each function it appears in.)
make: *** [foo.o] Error 1

I fixed the error by moving printf down a bit, in main.

The code works properly on my system when compiled in conforming mode, and
indeed when compiled in non-conforming mode!

I guess there is some call to another read-function my function is wrongly
linkted to,

That is almost certainly what's happening here - on /your/ system. It
doesn't happen on mine, at least not with either of these two compilation
lines:

gcc -o foo foo.c

and

gcc -W -Wall -ansi -pedantic -Wformat-nonliteral -Wcast-align
-Wpointer-arith -Wbad-function-cast -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -Winline -Wundef
-Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
-Wno-conversion -ffloat-store -O2 -o foo foo.c

 

[Andreas Griesmayer]

read() is called twice although only
called once, the first time before the first statement of main !

ok, that sentence is a bit twisted... let me try again: function read() is
executed twice although only called once by the source ...

---------------- SNIP ---------------
#include <stdio.h>
int bit_calc(signed char bits)
{ /* do something */
}

int read(){
int value;
printf("please enter a number between -128 and 127: ");
scanf("%d",&value);
return(value);
}

int main(){
printf("start of main()\n");
signed char bits = 0;

int countbits=0;
bits=read();
//...
return 0;
}

 

[Friedrich Dominicus]

Hi,

following piece of code causes a strange behavior when compiled with GCC
(Linux, Gentoo 3.3.5.20050130-r1). read() is called twice although only
called once, the first time before the first statement of main !
I guess there is some call to another read-function my function is wrongly
linkted to, it works fine if read() is renamed or static.
Compilation does not produce any warnings. Can anyone explain this behavior
to me or reproduce it with another compiler/operating system?

How did you have compiled that system?
Have you tried gcc -std=c99 -Wall .... ?

It could be that normal mode of gcc has the POSIX stuff defined by
default.

Regards
Friedrich

 

[Andreas Griesmayer]

That is almost certainly what's happening here - on /your/ system. It
doesn't happen on mine, at least not with either of these two compilation
lines:

wow, the second line _really_ is pedantic , thanks. Nevertheless, the
result of both lines calls read() twice on my system. Which system
(compiler/OS) do you have ?

-Wmissing-prototypes gives me the warning
calc_parity.c:6: warning: no previous prototype for `read'
which seems to be a sign that _my_ prototype is ignored. But still: i don't
think that GCC produces a correct program on my system. (and no warnings
with -Wall)

 

[Andreas Griesmayer]

Have you tried gcc -std=c99 -Wall .... ?

I tried now: same results and no warnings besides those due to the functions
i replaced by a stub.

thanks,
Andreas

 

[Richard Heathfield]

Andreas Griesmayer said:

Nevertheless, the
result of both lines calls read() twice on my system. Which system
(compiler/OS) do you have ?

I'm using gcc 2.95.3 under SuSE Linux.

-Wmissing-prototypes gives me the warning
calc_parity.c:6: warning: no previous prototype for `read'
which seems to be a sign that _my_ prototype is ignored.

int read() is not a prototype; it's merely a declaration.

int read(void) is a prototype.

But still: i don't think that GCC produces a correct program on my system.
(and no warnings with -Wall)

Then either there's something you're not telling us, or gcc is broken. I
hope you'll forgive me for assuming it's the former. "There's a bug in the
compiler" is an oft-cried cry, but the better you get at C, the less often
you'll cry it, because you'll learn (as we all learn) that the vast
majority of our bugs are of our own devising.

 

[Andreas Griesmayer]

int read() is not a prototype; it's merely a declaration.
int read(void) is a prototype.

thanks, so the compilation goes without warning now.

Then either there's something you're not telling us, or gcc is broken. I
hope you'll forgive me for assuming it's the former.

Sure I forgive you, I experienced the "the compiler is evil and the computer
is devil" - feeling often enough myself, usually it _is_ the user. But I
can't think of anything I didn't tell you and that would excuse the result
of the gcc run.

compiling the program at the end of the message with:
gcc -W -Wall -ansi -pedantic -Wformat-nonliteral -Wcast-align
-Wpointer-arith -Wbad-function-cast -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -Winline -Wundef
-Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
-Wno-conversion -ffloat-store -O2 calc_parity.c
doesn't produce any warnings or errors and creates a program that asks twice
for an input, the second input is taken for its computation.

Btw, I am not really that interested in computing parities. Its a students
program I use for some testing-like stuff. I experienced this strange
behavior when looking through the examples and hoped to find someone to
help me with an explanation.

Thanks,
Andreas

---- SNIP - warningless version-------------
#include <stdio.h>

int bit_calc(signed char);
int read(void);

int read(){
int value;
printf("please enter a number between -128 and 127: ");
scanf("%d",&value);
return(value);
}

/*--------------------------------------------------------------*/
int main(void){
signed char bits = 0;
int countbits=0;
printf("start of main()\n");


bits=read();
countbits = (bit_calc(bits));

printf("the paritybit is: %d\n",countbits);
return 0;
}

/*--------------------------------------------------------------*/
int bit_calc(signed char bits)
{

int count = 0;
int countbits = 0;
int mask = 0;

for(count=0;count<8;count++)
{
mask=(bits & (1 << count));
if (mask != 0)
{
countbits++;
}

}
return( countbits & 1);
}
---------------------------------------------------------------------

 

[David Resnick]

ok, that sentence is a bit twisted... let me try again: function read() is
executed twice although only called once by the source ...

---------------- SNIP ---------------
#include <stdio.h>
int bit_calc(signed char bits)
{ /* do something */
}

int read(){
int value;
printf("please enter a number between -128 and 127: ");
scanf("%d",&value);
return(value);
}

int main(){
printf("start of main()\n");
signed char bits = 0;

int countbits=0;
bits=read();
//...
return 0;
}

I'd suggest moving this to gnu.gcc.help, seems like a gcc issue rather
than a C one per se.

FYI, I tried your program on this gcc: gcc (GCC) 3.2.3 20030502 (Red
Hat Linux 3.2.3-34). Got only one request for input.

-David

 

[Andreas Griesmayer]

Andreas Griesmayer said:



I'm using gcc 2.95.3 under SuSE Linux.

I found another computer here with gcc 3.3.5-13 on debian (AMD64) that
creates the correct program. read() is called twice only on gcc
3.3.5.20050130-r1 (Intel P4) on gentoo.
Any ideas on other system details I could look at ?

thanks,
Andreas

 

[Richard Heathfield]

Andreas Griesmayer said:

I found another computer here with gcc 3.3.5-13 on debian (AMD64) that
creates the correct program. read() is called twice only on gcc
3.3.5.20050130-r1 (Intel P4) on gentoo.

I compiled your latest code and again it called read() only once.

Any ideas on other system details I could look at ?

I can see nothing in your code that would cause this problem. If you weren't
facing this immediate problem, I would have pointed out a few trillion -
er, hang on - a few things you could have done to make the program more
robust and maintainable, but they are really side issues for you right now.

I'm afraid I agree with David - you may indeed have exposed a gcc
conformance problem (with your particular version on your particular
system). Most odd. And he's right that your best course is to take it up in
gnu.gcc.help - tell them you've been to comp.lang.c and that one of their
most pedantic SOBs is sure it's not a bug in the program. That might help a
bit.

Having said that, I'm almost certain I can guess what they'll say: "well, if
you give a user function the same name as a system call, what did you
expect?!?" - and they'd kind of have a point, from their perspective.

From a comp.lang.c point of view, though, 'read' is in user namespace, and
there's nothing wrong with calling a function by that name, provided the
compiler is invoked in conforming mode.

You might find yourself falling between two newsgroups here.

 

[spibou]

#include <stdio.h>

int bit_calc(signed char);
int read(void);

int read(){
int value;
printf("please enter a number between -128 and 127: ");
scanf("%d",&value);
return(value);
}

/*--------------------------------------------------------------*/
int main(void){
signed char bits = 0;
int countbits=0;
printf("start of main()\n");


bits=read();
countbits = (bit_calc(bits));

printf("the paritybit is: %d\n",countbits);
return 0;
}

/*--------------------------------------------------------------*/
int bit_calc(signed char bits)
{

int count = 0;
int countbits = 0;
int mask = 0;

for(count=0;count<8;count++)
{
mask=(bits & (1 << count));
if (mask != 0)
{
countbits++;
}

}
return( countbits & 1);
}

The above compiles and behaves correctly with
gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
and
gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)
both on Pentium 4. Also with GCC 2.8.1 on
Solaris 8 on Sparc. Also with the Sun compiler.

I found another computer here with gcc 3.3.5-13 on debian (AMD64) that
creates the correct program. read() is called twice only on gcc
3.3.5.20050130-r1 (Intel P4) on gentoo.
Any ideas on other system details I could look at ?

Perhaps I'm being dense but I'm not clear on what
you're trying to achieve. Have you tried replacing
read with some other library function to see what
happens ?

But perhaps I shouldn't be asking questions since this
is getting more and more out of topic.

Spiros Bousbouras

 

[Richard Heathfield]

(e-mail address removed) said:

Perhaps I'm being dense but I'm not clear on what
you're trying to achieve. Have you tried replacing
read with some other library function to see what
happens ?

He already said that it works when read() is renamed or made static. Library
functions are neither here nor there, since his read() is a user-defined
function, not a library function.

His symptoms are a clear indication that the implementation is doing
something screwy.

But perhaps I shouldn't be asking questions since this
is getting more and more out of topic.

It's actually perfectly topical. He's asking if there's a problem with his C
program. That's a topical question, with a topical answer. Unfortunately,
the topical answer doesn't help him very much, but at least he's eliminated
the possibility that a bug in his program is causing the problem.

 

[spibou]

(e-mail address removed) said:



He already said that it works when read() is renamed or made static. Library
functions are neither here nor there, since his read() is a user-defined
function, not a library function.

But he hasn't said if the different name he's
tried was also the name of a library function.

His symptoms are a clear indication that the implementation is doing
something screwy.

Indeed and I was trying to establish if the screwy thing
only happens with read or also when other library names
are used. But then I realized that problems of the compiler
are off-topic.

It's actually perfectly topical. He's asking if there's a problem with his C
program. That's a topical question, with a topical answer.

Perhaps it started as "perfectly topical" but it is becoming clear
since the last several messages that it is a problem of the specific
compiler on the specific system.

Spiros Bousbouras

 

[Andreas Griesmayer]

Perhaps I'm being dense but I'm not clear on what
you're trying to achieve.

I have a program that does strange things, and I want to know why ;-)

Thanks everyone for testing on your systems !

 

[Richard Heathfield]

(e-mail address removed) said:

But he hasn't said if the different name he's
tried was also the name of a library function.


Indeed and I was trying to establish if the screwy thing
only happens with read or also when other library names
are used.

Oh, now I see what you were getting at. Sorry about that.

But then I realized that problems of the compiler are off-topic.

Yes, but it's a sensible thing to suggest all the same, although somehow I
doubt whether it will be a problem.

I think maybe what is happening is that his version of gcc is calling read()
in the startup code, for its own nefarious porpoises, and his version of
read() is being called instead of the system call. Just guessing, of
course.

Perhaps it started as "perfectly topical" but it is becoming clear
since the last several messages that it is a problem of the specific
compiler on the specific system.

Yes, I think we're coming to the end of our scope.

 

[Andreas Griesmayer]

(e-mail address removed) said:

Oh, now I see what you were getting at. Sorry about that.

sorry, i didn't get that too. I tried it with an other, completely innocent
function name when I realized that "read()" might be a bad idea.

Seems like we have a funny system here.

Thanks again,
Andreas

 

[Ike Naar]

ok, that sentence is a bit twisted... let me try again: function read() is
executed twice although only called once by the source ...

---------------- SNIP ---------------
#include <stdio.h>
int bit_calc(signed char bits)
{ /* do something */
}

int read(){
int value;
printf("please enter a number between -128 and 127: ");
scanf("%d",&value);
return(value);
}

int main(){
printf("start of main()\n");
signed char bits = 0;

int countbits=0;
bits=read();
//...
return 0;
}
-----------------------------------------

Compiled the above program with gcc 2.95.3, ran it, and it goes into an
infinite loop! When read() is renamed to e.g. Read(), it runs ok.
It does not make any difference whether the program is compiled without
additional flags, or in conforming mode (gcc -ansi -pedantic).

I had to make two minor changes to make this program compile correctly,
since this old gcc version does not support C99 syntax:
- moved the printf() in main() past the declarations of bits and countbits
- removed the //... comment

Fixing the prototypes of read() and main() to "int read(void)" and
"int main(void)" made no difference.

Of the compilers that I have access to, gcc 2.95.3 is the
only one that shows this strange behaviour.
The program works fine with gcc 2.96, gcc 3.2.1, gcc 3.2.2, gcc 3.4.5,
intel 8.1, Sun C 5.6, Sun C 5.8 and HP C B.11.11.04 .

 

[Richard Heathfield]

Ike Naar said:

Of the compilers that I have access to, gcc 2.95.3 is the
only one that shows this strange behaviour.

....and only on some platforms. Well, certainly not mine, where gcc 2.95.3
behaves immaculately on the OP's program (suitably deloused of C99 stuff,
obviously).

Weird.

 

[Andreas Griesmayer]

Compiled the above program with gcc 2.95.3, ran it, and it goes into an
infinite loop! When read() is renamed to e.g. Read(), it runs ok.
It does not make any difference whether the program is compiled without
additional flags, or in conforming mode (gcc -ansi -pedantic).

Of the compilers that I have access to, gcc 2.95.3 is the
only one that shows this strange behaviour.
The program works fine with gcc 2.96, gcc 3.2.1, gcc 3.2.2, gcc 3.4.5,
intel 8.1, Sun C 5.6, Sun C 5.8 and HP C B.11.11.04 .

Thanks !

Could you tell me the operating system (distribution)? I try to make a list
in gnu.gcc.help .

Regards,
Andreas