Migration from Sun C compiler to gcc

Question

I am in the midst of researching possible pitfalls of migrating from Sun C 5.9 to gcc (GCC) 3.4.6 on a Solaris 10 box for consistency with our other programs. Is there any guide or list of possible pitfalls available which we should look out for?

We have already narrowed down an issue with code of the following sort (known by us to be bad practice, but long existing):

char* stringLiteralPointer = "someStringLiteralValue";
strcpy(stringLiteralPointer , "anonStringLiteralValue"); //Crash here only with gcc

This error can be detected by using -Wwrite-strings and checking all the errors. Are there any other such warnings we should be aware of that could point out more such possible run-time errors from the differences in the gcc c compiler and the Sun C compiler?

Answer 1

This error can be detected by using -Wwrite-strings and checking all the errors

strlen(stringLiteralPointer , "anonStringLiteralValue"); 

is not valid in C. I got this error without any flag (warning):

[Error] too many arguments to function 'strlen'   

Are there any other such warnings we should be aware of that could point out more such possible run-time errors from the differences in the gcc c compiler and the Sun C compiler?

In GCC, to detect more warnings you can compile your code in C99 mode (-std=C99) with -Wall and -Wextra flags.

Answer 2

The strlen function take just a single argument of type const char* (which means it will accept a non-const char* argument).

Some older compilers might accept function calls with an incorrect number of arguments. You need to fix the code.

That's assuming your code actually uses strlen. As fernando.reyes suggests in a comment, it's likely you really meant strcpy rather than strlen (particularly since you don't use the result; calling strlen() and discarding the result doesn't make much sense).

In that case, the problem is that stringLiteralPointer points to (the array object associated with) a string literal. Attempting to modify such an array has undefined behavior. Some compilers might put string literals in read/write memory, but you should not depend on that.

Again, the solution is to fix your code. You need to arrange for stringLiteralPointer to point to an array that's not a string literal. One way to do this is to use malloc to allocate enough space (and be sure to check that the pointer returned by malloc is non-null). If your pointer already points to a string literal, you can probably also use the non-standard strdup function, which (attempts to) allocate a new read/write copy of the string and returns a pointer to it. Again, you need to confirm that the allocation succeeded.

Another alternative might be to use an array, rather than a pointer. This:

char *ptr = "literal";

causes ptr to point to a string that you're not allowed to modify. This:

char arr[] = "literal";

makes arr an array containing a read/write copy of the string literal.

And please make sure that the code in your question is the actual code you're compiling. Copy-and-paste it, don't re-type it. Please read this.

More generally, gcc has a number of options to enable extra warnings. If you compile your code with something like:

gcc -std=c99 -Wall -Wextra -O3 ...

you'll likely catch a number of questionable things in your code. The -std=c99 option tells gcc to (attempt) to conform to the 1999 ISO C standard; if your code is meant to be compliant to C90 (commonly but incorrectly called "ANSI C"), use -ansi rather than -std=c99. The -O3 option enables the maximum level of optimization; this causes the compiler to perform additional analysis that can also enable more warnings.

There are a number of C checkers that perform even more analysis than most compilers do. Lint was the original tool. Splint (formerly LCLint) is a modern implementation, and it's freely available here or (probably) via your system's package manager.