Re: A simple parser

jacob navia <jacob@xxxxxxxxxxxxxxxx> writes:
Keith Thompson wrote:
jacob navia <jacob@xxxxxxxxxxxxxxxx> writes:

Flash Gordon wrote:

<snip>
The return value is still non-standard.

???
Since when there is a standard return value?

This returns zero for no error, 1 for argument error
and 2 if the file could not be opened...
The standard return values for main() are EXIT_SUCCESS or 0 for
success, EXIT_FAILURE for failure. Any other values are non-portable.
In particular, there are real-world systems where "exit(1)" or
"return 1;" from main() will cause the program to terminate and
indicate *success* to the calling environment.
It's often possible to define return values other than the standard
ones, but they're likely to be system-specific, and they should be
clearly documented.
You didn't know that?

Excuse me but it is
int main(int argc,char *argv[])

"int" means at least 16 bits return value. I can choose more
tha 30 000 values, and I used 3:
zero for no error, one for argument error, and two for open failure
error. Other error codes (that I do not use) could be syntax error in
the source file, etc.

EXIT_SUCCESS or EXIT_FAILURE are just too few values to use.
Or you mean that all error codes are unnecessary and that
only "failure" should be returned instead of more detailed
error reports???

I can't understand the argumentation here, that is not based in
any standard whatsoever. "main" returns an "int", not a boolean
value of just success or failure. And that has a reason.

Not based on any standard whatsoever?? It's based on the C standard,
ISO/IEC 9899:1999.

C99 5.1.2.2.3p1:

... a return from the initial call to the main function is
equivalent to calling the exit function with the value returned by
the main function as its argument ...

C99 7.20.4.3p5:

Finally, control is returned to the host environment. If the value
of status is zero or EXIT_SUCCESS, an implementation-defined form
of the status _successful termination_ is returned. If the value
of status is EXIT_FAILURE, an implementation-defined form of the
status _unsuccessful termination_ is returned. Otherwise the
status returned is implementation-defined.

Note carefully that last sentence; for "exit(1);" or "return 1;", the
status returned is defined by the *implementation*, not by your own
program.

Error codes are an habit for me. I always use them to convey
more information to the calling program than just "failure"...

WHAT FAILED?

The file couldn't be opened? Syntax error in the file?

Error codes allow you to differentiate the different possibilities.

That's great if your implementation allows for it, but exit codes
cannot *portably* distinguish results other than success vs. failure.

Some concrete examples:

In Unix-like systems, all but the low-order 8 bits of the status are
silently ignored, so exit(256) has exactly the same effect as exit(0).
It's common for applications to use multiple return codes for
different failure modes (grep specifies 2 different failure codes;
curl currently specifies 76), but there's no universal standard other
than zero for success, non-zero for failure.

In VMS, the convention is that an odd-numbered status indicates
success and an even-numbered status indicates failure (with a lot more
rules for interpreting specific values). As a special case, in a C
program, a status of 0 is translated to 1, so that exit(0) will work
as expected; this translation is *not* done for exit(1). So "exit(0)"
and "exit(1)" both have exactly the same effect; both indicate that
the program terminated successfully.

It would be perfectly valid for an implementation to treat 0 as
success, 1 as failure, and map *all* non-zero status values to 1. (I
don't know of any systems that actually do this.)

Now if you want to define a set of status codes for your program, and
the program is intended to run only on some particular platform,
that's just fine. If you want to define the same set of status codes
for *all* platforms, even if it violates the established conventions
on some systems, I personally think it's a bad idea but you can go
ahead and do it if you insist.

If you think that success vs. failure just isn't enough information, I
don't necessarily disagree; your argument is with the C standard, not
with me.

Furthermore, if you want your program to convey extra information via
the exit status, you really should document it. I can't use the
information if I don't know it's there.

jacob, did you really not know this?

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <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.
.

Relevant Pages

  • Return value(s) from functions - any defacto standard?
    ... values that indicate success and fail. ... success, returns 0 for some calls and returns 1 on others. ... suppose if you want to mix in failure mode codes as returns from these ...
    (microsoft.public.vc.mfc)
  • Re: Why no segmentation fault
    ... return values as condition codes. ... a cleaner solution would have been for the C standard to specify ... In the Unix world that gave birth to C, 0 means success, and non-zero ...
    (comp.lang.c)
  • Re: Question concerning object-oriented programming
    ... I have the standard that "all methods, that do not return a value, ... shall return bool true or false, true on success, false on failure. ... or that there is always some value they can return that signifies failure. ...
    (comp.programming)
  • Re: indication
    ... This value is intended to be checked by the host environment to determine the outcome of the program run. ... There's also EXIT_FAILURE, and the two are the only values standard knows about, i.e. the only portable values to return to the environment. ... "success", ... means "failure" -- and these three ...
    (comp.lang.c)
  • Re: main return codes
    ... the C standard defines that 0 means a successful exit. ... for the environment to distinguish between success and failure. ... eight severity codes are actually used: ...
    (comp.lang.c)