Re: Question about gcc on OS X 10.0.4.11 Tiger

In article
<362956e7-319a-41b2-9074-130875daa6cb@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
,
piscesboy <oraclmaster@xxxxxxxxx> wrote:

On May 23, 10:42 pm, Bob Harris <nospam.News....@xxxxxxxxxxxxx
Harris.us> wrote:
In article
<7f6b9844-a1b5-42f1-aadb-6cc116726...@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
,



 piscesboy <oraclmas...@xxxxxxxxx> wrote:
Okay this is going to get a bit technical, but I'll try to keep it as
simple as possible:
I've been debugging this C app I've been tooling around with on XCode
and it turns out the
source of my troubles are calls to the fgets() function.  It seems to
cause bus errors and/or
segmentation faults wherever it show up. So, replace the function
with
something else and
problem solved right? Wrong. It turns out this very same code runs
fine on my other machine
running Linux and gcc 4.0.2. I strongly suspect that the source of my
troubles are in the version
of gcc I am using to compile, which brings me to my question:
How do I switch to a different version of gcc to compile with on OS X
10.4? For that matter, how
do I figure out how many different versions of gcc are available on
my
machine? I know there is
more than one version installed, since browsing my /usr/ directory
shows me that more than one version
exists, but when I do the gcc -V <version number> thing at compile
time, it tells me that version X of gcc
does not exist, when I just saw it in my /usr/ directory.
Has anyone else had this problem and how do you get around it?
Thanks.

fgets() is a libc function and is not really part of the compiler.

I do not know if there is a bug in fgets() or not, I've generally
found that claiming a libc function is broken vs my code is
generally a losing prepossession :-)

I have seen bugs in programs that have run for years on a given
operating system break when ported to a different OS because the
new OS or the compiler on that OS did not tolerate the existing
bug.

    char *
    fgets(char *restrict s, int n, FILE *restrict stream);

If I had to guess, the size of the buffer 's' is smaller than the
value 'n' AND the input is large enough to overflow the buffer.

Now assuming the buffer 's' is a local variable, overflowing on
one OS may overwrite another variable on the stack that is not
important.  However, maybe on Mac OS X, what is getting
overwritten is the return address, or maybe a pointer that is then
dereferenced.

I'm not saying this is the problem, but my 30+ year gut instinct
is that this is a programming error, and not a problem with
fgets().

                                        Bob Harris

Okay, Do me a favor: Paste the following code into foo.c and compile
using:
gcc -ansi - pedantic -Wall -O2 -o test foo.c

#define SUCCESS 1

int main(int argc, char* argv[]){
char *p;
p = fgets(p, 50, stdin);
printf("%s\n", p);
return SUCCESS;
}

Then run test. It should require you to type a line and upon pressing
return,
should echo the line.

I do not need to compile this. It is broken code.

'p' is suppose to have some storage behind it. In the code you
provide, 'p' contains random data. You are passing an address to
fgets(p,...) which is random. fgets() is storing your input
somewhere random in memory.

It is my guess that on Linux the random address is someplace
inside of your program that is not immediately harmful. On Mac OS
X, it is most likely an address that is outside the bounds of your
program so you are getting a SIGBUS error.

As others have suggested, you need to give 'p' some storage

#include <stdio.h>
#include <stdlib.h>

int
main(int argc, char* argv[])
{
char p[50];

if ( fgets(p, sizeof(p), stdin) == NULL ) {
perror("fgets()");
exit(EXIT_FAILURE);
}
printf("%s\n", p);
return(EXIT_SUCCESS);
}

This will work, and is better coding style, since the size of 'p'
is used as the maximum length to fgets().

EXIT_SUCCESS and EXIT_FAILURE are standard exit codes provided by
stdlib.h

Bob Harris
30+ years writing code
20+ years in C alone

I am compiling using
gcc version 4.0.1 thread model: posix Max OS X Power PC architecture.

Tell me the compiler version you use, and any errors you get, if any.
.

Relevant Pages

  • Re: Question about gcc on OS X 10.0.4.11 Tiger
    ... running Linux and gcc 4.0.2. ... How do I switch to a different version of gcc to compile with on OS X ... fgetsis a libc function and is not really part of the compiler. ... the size of the buffer 's' is smaller than the ...
    (comp.sys.mac.programmer.help)
  • Re: Question about gcc on OS X 10.0.4.11 Tiger
    ... running Linux and gcc 4.0.2. ... How do I switch to a different version of gcc to compile with on OS X ... fgetsis a libc function and is not really part of the compiler. ... the size of the buffer 's' is smaller than the ...
    (comp.sys.mac.programmer.help)
  • Re: malloc warning gcc > 4.0
    ... > When I compile this code: ... > char* p; ... I know it works with gcc 3.3.6. ... implicit prototype has a return type of int. ...
    (comp.lang.c.moderated)
  • Re: malloc warning gcc > 4.0
    ... > char* p; ... >warning: incompatible implicit declaration of built-in function 'malloc' ... I know it works with gcc 3.3.6. ... which should compile without error. ...
    (comp.lang.c.moderated)
  • Re: Segmentation fault when free
    ... Subject: Segmentation fault when free ... char *a; ... I use Kate to write programs, Makefiles to compile, use GCC, and use ddd in case of a trouble. ...
    (freebsd-questions)