piclist 2008\07\24\031101a >
Thread: What to do about compiler bug and source code?
www.piclist.com/techref/index.htm?key=what+about+compiler
face picon face BY : William \Chops\ Westfield email (remove spam text)




On Jul 23, 2008, at 1:51 PM, Tomás Ó hÉilidhe wrote:

>> we got bitten pretty hard on a change in pre-processor operation  
>> ordering
>> between gcc2.95 and gcc3.4...  Grr.
>
> I suppose the only thing you can say about it is that people should
> learn this stuff from the very start.

Not all the undefined issues are as obvious.  Consider:

  #define errno retrieve_errno_func()

  #define SUBSYSTEM_INCLUDE(subsystem, file) <subsystem/include/file>

  #include SUBSYSTEM_INCLUDE(posix, errno.h)

Each piece looks OK.  gcc2.95 pre-processes as intended, to:
   #include <posix/include/errno.h>
gcc3.4 preprocessed to:
   #include <posix/include/retrueve_errno_func()>
Oops.

> it would be great to have a tool that would scan through code  
> looking for instances in which code will behave differently on  
> different systems because of unspecified
> behaviour. It wouldn't even need to compile the code, it would just  
> spit
> out something like:
>     Warning: The statement on line 3 can have more than one effect  
> on different platforms

There's a whole class of tools called "static analysis" tools that do  
this sort of thing.  And for that matter, compilers themselves keep  
getting fussier as well; what WAS  accepted and compiled to correct  
code in one version may get warning messages from a later compiler.  
When we upgrade compilers, it's always a major effort to go through  
and address all the new warnings that get printed (some are actual  
errors,
some are spurious, some are due to a change in features, etc.  Policy  
is that no warning messages are allowed...)  Some things get changed,  
sometime obscure compiler switches are invoked to change behavior,  
sometimes we go and get the compiler changed to accept things the way  
we'd like them to be... ("It's all very nice that you check the  
printf arguments against the format descriptors, but we have our own  
version of printf with DIFFERENT meanings for %e and such, so you've  
got to at least have a way to turn it off!")

What you currently do (-pedantic -ansi -Wall) is a step in the right  
direction.

>
> I've heard of something called Lint ...
That's one of them.  See
  http://web.mit.edu/sunsoft_v5.1/www/c-compiler/user_guide/
lint.doc.html

There's also flexeLint, KLOCwork, Prefix, Coverity, and many others.  
Some cost big bucks.  Some are worth it (so we believe.)  Often one  
gets very frustrated with the false positives...

BillW

<1DC50138-4604-4AD5-AFEE-1B982B47F3CA@mac.com> quoted-printable

In reply to: <488799CD.6070103@lavabit.com>
See also: www.piclist.com/techref/index.htm?key=what+about+compiler
Reply You must be a member of the piclist mailing list (not only a www.piclist.com member) to post to the piclist. This form requires JavaScript and a browser/email client that can handle form mailto: posts.
Subject (change) What to do about compiler bug and source code?

month overview.

new search...