Re: 3 Questions

From: Peter Ajamian (
Date: 01/30/01

George Greer wrote:
> On Mon, 29 Jan 2001, Peter Ajamian wrote:
> >While I can see lots of reasons to avoid breaking a standard, why on
> >earth would anyone want to avoid adhering to one?
> The same reason the Linux kernel doesn't do Path MTU Black Hole Discovery
> detection even though an IETF draft RFC says it is "required." Because
> sometimes the standard is dumb.  In Linux's case, it's because PMTUBHD is
> both hard to get right without breaking other connectivity and because it
> encourages people to stupidly block all ICMP traffic.

And even so, it follows the standard in other ways.  They're not trying
to avoid the standard just for the sake of avoiding it or for minor
convenience, they have a good reason not to follow that particular
aspect of the standard.

Before I get into this, I'll say that I had dropped the EXIT_FAILURE
debate (doesn't mean I agreed with you just that I didn't see as
something worth dragging to the ground).  But since it has been brought
up again...

> In our case, it's
> because 0-ok, !0-(fail|special) makes perfect sense but some other
> operating systems muck that up.

In which case EXIT_SUCCESS and EXIT_FAILURE would work on those OS's.

> The NULL pointer is defined to always be 0
> no matter what the hardware deems it to be,

I think this is what you mean, but just a point of clarification:

When 0 is casted as a pointer it must be converted to NULL, however the
in-memory representation of NULL does not have to be all-bits-zero,
indeed there are cases when it cannot be all-bits-zero (if all-bits-zero
points to a valid area of memory then to use all-bits-zero for NULL
would actually break the standard).  Thus if you attempt to clear an
area of memory with calloc or memset it can be dangerous to assume that
pointers stored in that area of memory will be NULL.

Now if you're quite sure that the program your working on will never be
compiled on a platform that uses a value other than all-bits-zero to
represent NULL in memory then go ahead and clear memory this way.  But
consider that when you're working on an open source app you really don't
know what platform your app will be compiled on, the best you can do is
speculate and hope the odds are in your favor.

> why couldn't they have done the
> same thing (and much easier to do too) for exit codes? That and they made
> the #define name exceedingly long for the replacement.

Granted it is a bit long, but it only takes, what 2 seconds to type?
You can always #define it to something shorter if you want.

> In our case, 0=ok,

That's fine and it follows the ANSI (I can't speak for C99 not too
familiar with it yet) standard.  In my own programs I tend to prefer
EXIT_SUCCESS for better readability.

> 1=fail,

That will work on most platforms but it does not follow the ANSI
standard.  I prefer to use EXIT_FAILURE for the sake of both portability
and readability.

> nothing else special. Maybe in the future 2=db-load-failure but
> that's not right now but available.

I would do this...

#define EXIT_DBFAIL 2

Then use EXIT_DBFAIL.  It does not follow the standard any more than 2
does, but it does make it easier to change in case someone really did
need to compile the program on a legacy platform.  If you then find a
platform that does not support 2 it is easy to enclose it in a #if #else
#endif block which can set EXIT_DBFAIL to EXIT_FAILURE for that
particular platform.

Regards, Peter

   | FAQ: |
   | Archives: |

This archive was generated by hypermail 2b30 : 12/03/01 PST