What gcc options guarantee more portable C code

[lovecreatesbeauty]

On gcc, which version of C standard has the most compliant: -c89, -ansi
or c99? For more portable C code, which options should be applied to
compilation?

Can the following options guarantee the most portable C code for
different environment?

gcc -ansi -pedantic -Wall test.c
--
lovecreatesbeauty

[Marc Boyer]

Le 15-06-2006, lovecreatesbeauty <lo***************@gmail.com> a écrit*:

On gcc, which version of C standard has the most compliant: -c89, -ansi
or c99? For more portable C code, which options should be applied to
compilation?

Can the following options guarantee the most portable C code for
different environment?

gcc -ansi -pedantic -Wall test.c

Can't you read the documentation of GCC ?
To compile c89 code, the option is -std=c89.
Support of c99 is not universal today, so, when looking at
'portability', you could restrict yourself to c89.

Other options are there to warn you when you compile some code
that gcc find suspect.

Marc Boyer

[CBFalconer]

lovecreatesbeauty wrote:

.... snip ... Can the following options guarantee the most portable C code for
different environment?

gcc -ansi -pedantic -Wall test.c

Try "gcc -W -Wall -ansi -pedantic -Wwrite-strings -Wfloat-equal"

--
Chuck F (cb********@yahoo.com) (cb********@maineline.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE maineline address!

[lovecreatesbeauty]

Marc Boyer wrote:

Can't you read the documentation of GCC ?
To compile c89 code, the option is -std=c89.
Support of c99 is not universal today, so, when looking at
'portability', you could restrict yourself to c89.
Other options are there to warn you when you compile some code
that gcc find suspect.

Thank you. But there are total 8933 lines in gcc manual document in
Debian Linux 3.1. Your expertise suggestion can just point out the
right selection from among nearly ten thousand lines of information.

CBFalconer wrote:

Can the following options guarantee the most portable C code for
different environment?
gcc -ansi -pedantic -Wall test.c

Try "gcc -W -Wall -ansi -pedantic -Wwrite-strings -Wfloat-equal"

Thank CBFalconer for the kind help.

lovecreatesbeauty

[tomstdenis]

CBFalconer wrote:

lovecreatesbeauty wrote:

... snip ...

Can the following options guarantee the most portable C code for
different environment?

gcc -ansi -pedantic -Wall test.c

Try "gcc -W -Wall -ansi -pedantic -Wwrite-strings -Wfloat-equal"

I dunno if that includes shadows but throw in -Wshadow as well if it
doesn't.

Tom

[lovecreatesbeauty]

to********@gmail.com wrote:

CBFalconer wrote:

Try "gcc -W -Wall -ansi -pedantic -Wwrite-strings -Wfloat-equal"

I dunno if that includes shadows but throw in -Wshadow as well if it
doesn't.

I check gcc manual again and find that -Wall doesn't cover -Wshadow.
I'm sorry if I misunderstood you.

lovecreatesbeauty

[tomstdenis]

lovecreatesbeauty wrote:

to********@gmail.com wrote:

CBFalconer wrote:

Try "gcc -W -Wall -ansi -pedantic -Wwrite-strings -Wfloat-equal"

I dunno if that includes shadows but throw in -Wshadow as well if it
doesn't.

I check gcc manual again and find that -Wall doesn't cover -Wshadow.
I'm sorry if I misunderstood you.

Then add it. -Wshadow isn't for portability but a lot of beginners
seem to make that mistake, e.g.

int x = 5;
while (somethingelse != 0) {
int x;
for (x = 0; x < 17; x++) { ... }
}
printf("Why is %d==5 it should be 17!!!???\n", x);

Clearly that's a bit contrived but when you use variables like i, j, x,
y, z as loop counters it's trivial to re-use them in nested blocks.

For my code I typically use

-Wall -Wsign-compare -W -Wshadow -Wno-unused-parameter

With at least -O2 or -O3. Turning on optimization is required for
several warnings to fully work.

so if you used

--std=c99 -pedantic -O2 -Wall -Wsign-compare -W -Wshadow
-Wno-unused-parameter

You're likely to catch most common programming mistakes as well as
standards violations. The trick is to not only use these flags but
then ADDRESS the diagnostics raised. Too many people use -Wall then
ignore all the output because "my code is right" syndrome kicks in.

Tom

[Andrew Poelstra]

On 2006-06-15, to********@gmail.com <to********@gmail.com> wrote:

CBFalconer wrote:

lovecreatesbeauty wrote:

>

... snip ...

> Can the following options guarantee the most portable C code for
> different environment?
>
> gcc -ansi -pedantic -Wall test.c

Try "gcc -W -Wall -ansi -pedantic -Wwrite-strings -Wfloat-equal"

I dunno if that includes shadows but throw in -Wshadow as well if it
doesn't.

This from Richard Heathfield:
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

(You'll have to un-linewrap that a fair bit).

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
I know that area of town like the back of my head.

[John Bode]

lovecreatesbeauty wrote:

On gcc, which version of C standard has the most compliant: -c89, -ansi
or c99? For more portable C code, which options should be applied to
compilation?

Can the following options guarantee the most portable C code for
different environment?

gcc -ansi -pedantic -Wall test.c

No, because "standard-compliant" does not necessarily imply "portable."
Code that assumes a particular endianness or uses bitfields to model
architecture-specific structures or relies on a platform-specific API
may compile cleanly with the above command, yet still not be portable
(or at least not maximally so).

Don't get me wrong, it's good practice, and it will catch some obvious
errors that may affect portability, but it won't guarantee that the
code is portable.

[CBFalconer]

to********@gmail.com wrote:

CBFalconer wrote:

lovecreatesbeauty wrote:

... snip ...

Can the following options guarantee the most portable C code for
different environment?

gcc -ansi -pedantic -Wall test.c

Try "gcc -W -Wall -ansi -pedantic -Wwrite-strings -Wfloat-equal"

I dunno if that includes shadows but throw in -Wshadow as well if
it doesn't.

It doesn't, and adding it is a bad idea. There are times when you
deliberately want to hide an outer scoped identifier, and shadowing
it with a local one is the ideal method.

....
int important; /* critical to the rest of the system */
....
int mybiglongfunctionNOTusingimportant(params) {
....
int local;
int impossible;
...
important = whatever; /* absent minded typo for impossible */
...
}

The above will be perfectly legal coding, but buggy. The bug will
cause total implosion elsewhere. By simply relabelling impossible
as important we prevent such from ever occuring. Shadow good, bug
bad.

--
Chuck F (cb********@yahoo.com) (cb********@maineline.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE maineline address!

[tomstdenis]

CBFalconer wrote:

It doesn't, and adding it is a bad idea. There are times when you
deliberately want to hide an outer scoped identifier, and shadowing
it with a local one is the ideal method.

...
int important; /* critical to the rest of the system */
...
int mybiglongfunctionNOTusingimportant(params) {
....
int local;
int impossible;
...
important = whatever; /* absent minded typo for impossible */
...
}

The above will be perfectly legal coding, but buggy. The bug will
cause total implosion elsewhere. By simply relabelling impossible
as important we prevent such from ever occuring. Shadow good, bug
bad.

I don't get the comment. -Wshadow kicks in if you had "important" as a
local variable to the current nesting level. You don't so that's not a
shadowing diagnostic [one way or another].

Also it's bad practice to use locals which you know are going to be
named as globals [or at least externably linkable] elsewhere.

This is why you don't have

void func(void)
{
int fopen = 4;

// ... blah blah blah
}

Tom

[Keith Thompson]

CBFalconer <cb********@yahoo.com> writes:

lovecreatesbeauty wrote:

... snip ...

Can the following options guarantee the most portable C code for
different environment?

gcc -ansi -pedantic -Wall test.c

Try "gcc -W -Wall -ansi -pedantic -Wwrite-strings -Wfloat-equal"

Better yet, try gnu.gcc.help.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[spibou]

to********@gmail.com wrote:

CBFalconer wrote:

It doesn't, and adding it is a bad idea. There are times when you
deliberately want to hide an outer scoped identifier, and shadowing
it with a local one is the ideal method.

...
int important; /* critical to the rest of the system */
...
int mybiglongfunctionNOTusingimportant(params) {
....
int local;
int impossible;
...
important = whatever; /* absent minded typo for impossible */
...
}

The above will be perfectly legal coding, but buggy. The bug will
cause total implosion elsewhere. By simply relabelling impossible
as important we prevent such from ever occuring. Shadow good, bug
bad.

I don't get the comment. -Wshadow kicks in if you had "important" as a
local variable to the current nesting level. You don't so that's not a
shadowing diagnostic [one way or another].

I think he was trying to give an example where you *would* want to use
shadowing ie name the variable inside the function important instead of
impossible.

[CBFalconer]

sp****@gmail.com wrote:

to********@gmail.com wrote:

CBFalconer wrote:

It doesn't, and adding it is a bad idea. There are times when you
deliberately want to hide an outer scoped identifier, and shadowing
it with a local one is the ideal method.

...
int important; /* critical to the rest of the system */
...
int mybiglongfunctionNOTusingimportant(params) {
....
int local;
int impossible;
...
important = whatever; /* absent minded typo for impossible */
...
}

The above will be perfectly legal coding, but buggy. The bug will
cause total implosion elsewhere. By simply relabelling impossible
as important we prevent such from ever occuring. Shadow good, bug
bad.

I don't get the comment. -Wshadow kicks in if you had "important"
as a local variable to the current nesting level. You don't so
that's not a shadowing diagnostic [one way or another].

I think he was trying to give an example where you *would* want to
use shadowing ie name the variable inside the function important
instead of impossible.

Exactly. It is somewhat analagous to the practice of putting the
constant first in an equality test to have the compiler help find
multilegged creatures:

if (123 == foo) ...

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[Keith Thompson]

CBFalconer <cb********@yahoo.com> writes:

sp****@gmail.com wrote:

to********@gmail.com wrote:

> CBFalconer wrote:

It doesn't, and adding it is a bad idea. There are times when you
deliberately want to hide an outer scoped identifier, and shadowing
it with a local one is the ideal method.

...
int important; /* critical to the rest of the system */
...
int mybiglongfunctionNOTusingimportant(params) {
....
int local;
int impossible;
...
important = whatever; /* absent minded typo for impossible */
...
}

The above will be perfectly legal coding, but buggy. The bug will
cause total implosion elsewhere. By simply relabelling impossible
as important we prevent such from ever occuring. Shadow good, bug
bad.

I don't get the comment. -Wshadow kicks in if you had "important"
as a local variable to the current nesting level. You don't so
that's not a shadowing diagnostic [one way or another].

I think he was trying to give an example where you *would* want to
use shadowing ie name the variable inside the function important
instead of impossible.

Exactly. It is somewhat analagous to the practice of putting the
constant first in an equality test to have the compiler help find
multilegged creatures:

if (123 == foo) ...

Yes, it's equally ugly. 8-)}

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Andrew Poelstra]

On 2006-06-15, Keith Thompson <ks***@mib.org> wrote:

CBFalconer <cb********@yahoo.com> writes:

sp****@gmail.com wrote:

to********@gmail.com wrote:
> CBFalconer wrote:

> It doesn't, and adding it is a bad idea. There are times when you
> deliberately want to hide an outer scoped identifier, and shadowing
> it with a local one is the ideal method.
>
> ...
> int important; /* critical to the rest of the system */
> ...
> int mybiglongfunctionNOTusingimportant(params) {
> ....
> int local;
> int impossible;
> ...
> important = whatever; /* absent minded typo for impossible */
> ...
> }
>
> The above will be perfectly legal coding, but buggy. The bug will
> cause total implosion elsewhere. By simply relabelling impossible
> as important we prevent such from ever occuring. Shadow good, bug
> bad.

I don't get the comment. -Wshadow kicks in if you had "important"
as a local variable to the current nesting level. You don't so
that's not a shadowing diagnostic [one way or another].

I think he was trying to give an example where you *would* want to
use shadowing ie name the variable inside the function important
instead of impossible.

Exactly. It is somewhat analagous to the practice of putting the
constant first in an equality test to have the compiler help find
multilegged creatures:

if (123 == foo) ...

Yes, it's equally ugly. 8-)}

Not to mention that it can't fix confusion at statements like this:

if (x = printf ("%s", s))
{
/* If s isn't a null string, do this... */
}

It'll just make your coding style seem inconsistant.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
I know that area of town like the back of my head.

[Ben Pfaff]

Andrew Poelstra <ap*******@localhost.localdomain> writes:

Not to mention that it can't fix confusion at statements like this:

if (x = printf ("%s", s))
{
/* If s isn't a null string, do this... */
}

I hope you don't actually write code like that. The following
is much more straightforward:

if (*s != '\0') {
fputs (s, stdout);
/* s isn't a null string, do something... */
}
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Harald van Dijk]

Ben Pfaff wrote:

Andrew Poelstra <ap*******@localhost.localdomain> writes:

Not to mention that it can't fix confusion at statements like this:

if (x = printf ("%s", s))
{
/* If s isn't a null string, do this... */
}

I hope you don't actually write code like that. The following
is much more straightforward:

if (*s != '\0') {
fputs (s, stdout);
/* s isn't a null string, do something... */
}

And even if you must test with printf, it can be more clearly (in my
opinion) written as

if((x = printf("%s", s)) != 0) {
/* ... */
}

[CBFalconer]

Harald van D?k wrote:

Ben Pfaff wrote:

Andrew Poelstra <ap*******@localhost.localdomain> writes:

Not to mention that it can't fix confusion at statements like this:

if (x = printf ("%s", s))
{
/* If s isn't a null string, do this... */
}

I hope you don't actually write code like that. The following
is much more straightforward:

if (*s != '\0') {
fputs (s, stdout);
/* s isn't a null string, do something... */
}

And even if you must test with printf, it can be more clearly
(in my opinion) written as

if((x = printf("%s", s)) != 0) {
/* ... */
}

And everything is much less likely to crash with:

if (s && *s) {
fputs(s, stdout);
/* do something with non-empty string */
}

--
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[lovecreatesbeauty]

Harald van D?k wrote:

Andrew Poelstra <ap*******@localhost.localdomain> writes:

Not to mention that it can't fix confusion at statements like this:
if (x = printf ("%s", s))
{
/* If s isn't a null string, do this... */
} And even if you must test with printf, it can be more clearly (in my
opinion) written as
if((x = printf("%s", s)) != 0) {
/* ... */
}

How about just as following in case of no need of one temporary:
if(printf("%s", s) != 0)
{
/* ... */
}

CBFalconer wrote: Ben Pfaff wrote:

I hope you don't actually write code like that. The following
is much more straightforward:
if (*s != '\0') {
fputs (s, stdout);
/* s isn't a null string, do something... */
}

And everything is much less likely to crash with:
if (s && *s) {
fputs(s, stdout);
/* do something with non-empty string */
}

Why both of you are apt to check the argument of fputs and not like
other people to check the return value of printf? Even though the
argument (s, *s) is available, the function call can fail also, right?

I'm sorry if what I say offended one of you.

lovecreatesbeauty

[Andrew Poelstra]

On 2006-06-16, Harald van Dijk <tr*****@gmail.com> wrote:

Ben Pfaff wrote:

Andrew Poelstra <ap*******@localhost.localdomain> writes:

> Not to mention that it can't fix confusion at statements like this:
>
> if (x = printf ("%s", s))
> {
> /* If s isn't a null string, do this... */
> }

I hope you don't actually write code like that.

Of course not. It was, however, one of my more intersting examples.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
I know that area of town like the back of my head.

[Andrew Poelstra]

On 2006-06-16, lovecreatesbeauty <lo***************@gmail.com> wrote:

Why both of you are apt to check the argument of fputs and not like
other people to check the return value of printf? Even though the
argument (s, *s) is available, the function call can fail also, right?

I'm sorry if what I say offended one of you.

I rarely care whether or not a printf call succeeded; in general, I
don't pay too much attention to my UI. (I leave those issues for
whiney testers to find).

You have a point though, and neither of us have a right to be
offended.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
I know that area of town like the back of my head.

[Ian Collins]

Andrew Poelstra wrote:

On 2006-06-16, lovecreatesbeauty <lo***************@gmail.com> wrote:

Why both of you are apt to check the argument of fputs and not like
other people to check the return value of printf? Even though the
argument (s, *s) is available, the function call can fail also, right?

I'm sorry if what I say offended one of you.

I rarely care whether or not a printf call succeeded; in general, I
don't pay too much attention to my UI. (I leave those issues for
whiney testers to find).

That's a very irresponsible attitude. Don't you accept responsibility
for your own code?

--
Ian Collins.

[Keith Thompson]

Ian Collins <ia******@hotmail.com> writes:

Andrew Poelstra wrote:

On 2006-06-16, lovecreatesbeauty <lo***************@gmail.com> wrote:

Why both of you are apt to check the argument of fputs and not like
other people to check the return value of printf? Even though the
argument (s, *s) is available, the function call can fail also, right?

I'm sorry if what I say offended one of you.

I rarely care whether or not a printf call succeeded; in general, I
don't pay too much attention to my UI. (I leave those issues for
whiney testers to find).

That's a very irresponsible attitude. Don't you accept responsibility
for your own code?

There's always the question of what to do if printf fails. Printing
an error message doesn't seem like a sensible response. It's
conceivable (but by no means certain) that ignoring the error and
continuing to run is the best response.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Andrew Poelstra]

On 2006-06-16, Ian Collins <ia******@hotmail.com> wrote:

Andrew Poelstra wrote:

On 2006-06-16, lovecreatesbeauty <lo***************@gmail.com> wrote:

Why both of you are apt to check the argument of fputs and not like
other people to check the return value of printf? Even though the
argument (s, *s) is available, the function call can fail also, right?

I'm sorry if what I say offended one of you.

I rarely care whether or not a printf call succeeded; in general, I
don't pay too much attention to my UI. (I leave those issues for
whiney testers to find).

That's a very irresponsible attitude. Don't you accept responsibility
for your own code?

I ensure that it runs correctly. I usually do not ensure that the user
knows that it runs correctly. Perhaps that is irresponsible.

Of course, I can't think of what I would do if printf was messing up;
a failure to output suggests system problems outside of my control or
diagonoses.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
I know that area of town like the back of my head.

[Ian Collins]

Keith Thompson wrote:

Ian Collins <ia******@hotmail.com> writes:

Andrew Poelstra wrote:

I rarely care whether or not a printf call succeeded; in general, I
don't pay too much attention to my UI. (I leave those issues for
whiney testers to find).

That's a very irresponsible attitude. Don't you accept responsibility
for your own code?

There's always the question of what to do if printf fails. Printing
an error message doesn't seem like a sensible response. It's
conceivable (but by no means certain) that ignoring the error and
continuing to run is the best response.

My comment was directed more at the leaving stuff for the testers to
find attitude, rather than the specifics of failing printf.

--
Ian Collins.

[Ian Collins]

Andrew Poelstra wrote:

On 2006-06-16, Ian Collins <ia******@hotmail.com> wrote:

Andrew Poelstra wrote:

I rarely care whether or not a printf call succeeded; in general, I
don't pay too much attention to my UI. (I leave those issues for
whiney testers to find).

That's a very irresponsible attitude. Don't you accept responsibility
for your own code?

I ensure that it runs correctly. I usually do not ensure that the user
knows that it runs correctly. Perhaps that is irresponsible.

Of course, I can't think of what I would do if printf was messing up;
a failure to output suggests system problems outside of my control or
diagonoses.

Or simply passing the parameters in the wrong order or providing the
wrong format.

I just don't like the silo mentality that can creep in when developers
delegate what I consider developer testing to testers.

--
Ian Collins.

[Ian Collins]

Keith Thompson wrote:

There's always the question of what to do if printf fails. Printing
an error message doesn't seem like a sensible response. It's
conceivable (but by no means certain) that ignoring the error and
continuing to run is the best response.

Just as an aside, have you considered that there as at least two ways
printf can fail?

It can find and internal error and return an error value.

It can output something other than the expected output due to programmer
error.

The former is rare seldom tested for, the latter more common and in my
opinion, should be tested by the programmer in his/her unit tests.

--
Ian Collins.

[Peter Nilsson]

lovecreatesbeauty wrote:

Marc Boyer wrote:

Can't you read the documentation of GCC ?
To compile c89 code, the option is -std=c89.
Support of c99 is not universal today, so, when looking at
'portability', you could restrict yourself to c89.
Other options are there to warn you when you compile some code
that gcc find suspect.
Thank you. But there are total 8933 lines in gcc manual document in
Debian Linux 3.1.

If you put a little more effort in to learning how to search such large
documents yourself, you'll find that this will help considerably in the
long term.

Very few of the 'experts' have encyclopaedic memories. They don't
waste their time trying to memorise all the answers, they content
themselves with knowing how and where to find them.

You know the where, it's the how you're struggling with. Broadcast
emails to usenet is one method, but it's about 10th on the ordered
list of things to try.
Your expertise suggestion can just point out the
right selection from among nearly ten thousand lines of information.

CBFalconer wrote:

Can the following options guarantee the most portable C code for
different environment?
gcc -ansi -pedantic -Wall test.c

Try "gcc -W -Wall -ansi -pedantic -Wwrite-strings -Wfloat-equal"

Thank CBFalconer for the kind help.

Are you quoting this elsethread message to somehow shame Marc,
or inform the clc community of the responses you'ld prefer?

Try digesting some of the answers you receive. The answers may
not be what you want, but they might be what you _need_. Marc's
response is clear and actually more informative than Chuck's!

Your subject question was "What gcc options guarantee more
portable C code". The correct answer is that YOU control the
portability of your code, not gcc.

As I see it, you've received answers to an entirely different question,
namely how to make gcc conforming and what warnings are useful
for debugging. That question is better asked in a gnu/gcc group
since the C standard doesn't specify how to invoke given
implementations.

I will say that Chuck missed an option to do with floating point
calculations on x86 machines. [I couldn't recall it, but I was able
to find it in a matter of minutes using google; and I'm not even
an expert... ;-]

--
Peter