What gcc options guarantee more portable C code

[Andrew Poelstra]

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

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

 

[Andrew Poelstra]

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.

 

[Ian Collins]

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?

 

[Keith Thompson]

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.

 

[Andrew Poelstra]

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.

 

[Ian Collins]

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]

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]

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.

 

[Peter Nilsson]

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.


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... ;-]