Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I recently did a fresh OS reinstall - switched from openSUSE to Xubuntu. I had backed up all my scientific data post-processing scripts (written in C or in FORTRAN). Code I had recently used and worked error free on SUSE gives errors mostly related to outputting character data...help!

example error message:

FBDcode.c:144:2: warning: format ‘%s’ expects argument of type ‘char *’,  
                 but argument 3 has type ‘char (*)[100]’ [-Wformat]

line 144 in my .c file is:

fscanf(infile_PP, "%s %lf\n", &temp_str, &solvent_molec_wt);

variable temp_str is defined earlier in this manner:

char temp_str[100];
share|improve this question
1  
for vote-to-closers I believe this is relevant on Ubuntu and ontopic. –  gertvdijk Jan 22 '13 at 21:58

1 Answer 1

Why the code generates warnings

You want to pass temp_str without the & since arrays are passed by reference by default.

If you need to pass a specific member i of the array, you can pass &temp_str[i] without warnings, including &temp_str[0].

Why the code compiles on openSUSE but generates a warning on Ubunutu

I have both openSUSE 12.2 and Ubuntu 12.10 on my computer and tried it several ways. Both use gcc 4.7.1.

openSUSE does not generate the compiler warning because the appropriate warnings are not on by default. If you compile your code on openSUSE with warnings on (most commonly -Wall), you will see the same compiler warning as you do on Ubuntu.

Ubuntu uses dpkg-buildflags to set the default settings. By default, Ubuntu uses -Wformat (which is generating the warning about fscanf and would be included when using -Wall) and -Werror=format-security, which turns warnings from -Wformat-security into errors (and is not included in -Wall).

You can view these settings in the terminal with dpkg-buildflags --dump and dpkg-buildflags --status.

What are Compiler Warnings?

Coders learn about compiler errors quickly. When code has typos, syntax errors, or the compiler is able to detect certain other problems, the compiler issues errors and stops. In these cases, we say the code won't compile.

But there are many more cases where the compiler thinks there might be an error, or notices legal code that might have certain problems. In these cases, the compiler issues warnings but will usually finish compiling the code.

It's important to look at the warnings. Most of the time, the warnings should be treated as errors and fixed even when the code compiles. If the warnings are ignored or not seen in the first place, the programmer may falsely think there is nothing wrong with the code. The resulting code may run fine or appear to run fine. But these warnings very often mean there's a problem waiting to happen. When conditions change later on, the code might produce the wrong result or even lead to undefined behavior, causing crashes. It is very hard to find this kind of bug because the programmer is starting from an assumption that code has no problems.

In gcc, the command line option -Wall shows most warnings. Options that start with -W are about warnings. These are in the man page. In this case -Wall shows all (really most) warnings. It is a very good idea to always use the -Wall option. The GNU gcc documentation has a lot more information on warnings and settings.

An excellent new book that explains using Make files and other tools to set compile options is 21st Century C from O'Reilly Media, another very good book is Autotools from No Starch Press

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.