 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / Mac Programming / May 2008Question about gcc on OS X 10.0.4.11 Tiger
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. In article <7f6b9844-a1b5-42f1-aadb-6cc116726cb2@m3g2000hsc.googlegroups.com> , > Okay this is going to get a bit technical, but I'll try to keep it as > simple as possible: [quoted text clipped - 22 lines] > 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 On May 23, 10:42 pm, Bob Harris <nospam.News....@remove.Smith- Harris.us> wrote: > In article > <7f6b9844-a1b5-42f1-aadb-6cc116726...@m3g2000hsc.googlegroups.com> [quoted text clipped - 55 lines] > > 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 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. In article <362956e7-319a-41b2-9074-130875daa6cb@a70g2000hsh.googlegroups.com>, > Okay, Do me a favor: Paste the following code into foo.c and compile > using: [quoted text clipped - 17 lines] > > Tell me the compiler version you use, and any errors you get, if any. The first error I get is one in my head that shouts "p is not initialized". I haven't tried compiling this, but I would guess that, according to the C standard, this program has 'undefined behavior'. Try to declare p as char * p = malloc(51); .... free(p) or char p[51]; instead. Reinder In article <362956e7-319a-41b2-9074-130875daa6cb@a70g2000hsh.googlegroups.com >, > On May 23, 10:42 pm, Bob Harris <nospam.News....@remove.Smith- > Harris.us> wrote: [quoted text clipped - 74 lines] > 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. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.