Re: Compilation problems??

In article <5tg1hk$h3e_at_netserv.waikato.ac.nz>, Simon Travaglia <simonSPAMFREE_at_waikato.ac.nz> wrote:
>Yes, one point for you.

Sort of.

I defy Alicia to make a return code of 99 indicate success on AmigaDOS, where it will cause any script to abort instantly. :)

Yes, really. It will *KILL THE PARENT SCRIPT*. Generally, no one ever returns any status over 20. 0 is success, and successively higher numbers indicate successively worse failures. Any given script will have a failure tolerance, but I have never seen anyone try to use one over 21, which is high enough.

The OS spec says that 5 is a warning, 10 is an error, and 20 is a very fatal error.

>"Shit, there are users out there who are never going to read my manual,
>if I write one in the first place, so I know, I'll throw a "#include <errno>"
>in the top of my code, so THEN I can say "exit( EPERM)", and not only
>will it work, and compile on all platforms that have errno in /usr/include,
>but it will be available to the competant Analyst to figure out what the
>exit status was without wondering what whim you were in when you wrote
>that part of the code...

I would argue this; EPERM is not in all <errno.h>'s. Further more, I can point you at a Real Live System where there is a very good chance that this would indicate success, because it turns out that 1 is a success status. (0 is a failure, on that OS, but exit() and return from main specially take steps to "actually" produce a 1 exit code if you return 0 from main...)

>> If I write a program and decide that exit(99) indicates failure due to
>> an inability to allocate sufficient memory for a data object, that is
>> EXACTLY what an exit code of 99 will mean ON EVERY SINGLE PLATFORM/OS
>> THAT I CHOOSE TO PORT MY PROGRAM TO.
Unless the OS has different meanings; for instance, on VMS, as I recall, an exit code of 99 is a *SUCCESS*, because the low-order bit is set. You're also passing back various information, *ALL OF WHICH IS RIGIDLY DEFINED IN MEANING BY THE ENVIRONMENT*. So, you really mean "whatever PC running an OS I'm familiar with that I choose to port my program to". This is exactly the point people are getting at when they say it's not portable.

>And you have that right, no-one's trying to steal from you the ability
>to write poor code.

She may have the "right", however, she does not have the ability.

I am unable to persuade my computer to return a value of 256 to the calling environment. It just doesn't happen. Never has, never will. I get a 0 if I try.

The environment can and will impose limitations on what you can return. Some environments impose the limitation that nothing you return is even noticed, no matter what it is.

This is why the standard gives you a bit of room to use meaningful values *in a maximally portable way*.

I mean, a lot of people seem to think C89 was put together by a bunch of twits, but really, they've done a bang-up job of finding the *real* limit on what features can be provided, and providing those features.

-s

-- 
Copyright 1997 Peter Seebach - seebs at solon.com - C/Unix Wizard
I am not actually staff_at_quantcom.com but junk mail is accepted there.
The *other* C FAQ, the hacker FAQ, et al.  http://www.solon.com/~seebs
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.