HEADS DOWN

[Sean C. Farley]

On Sat, 12 May 2007, Robert Watson wrote:

> On Fri, 11 May 2007, Sean C. Farley wrote:
>
>> On Fri, 11 May 2007, Andrey Chernov wrote:

<snip>

>>> I suggest to change errx() to warnx()+return(failure).
>> 
>> No need to worry any longer; I changed them into warnx().  What value
>> should I give errno?  I do not want the program to receive a random
>> error code. The first warnx() could be EINVAL.  The second warnx()
>> would be a coding error on my part.  EDOOFUS would fit.  :)  I know I
>> should not use it. EINVAL?
>
> Actually, I'm not convinced that crashing the program isn't the right
> answer.  If an application corrupts memory managed by libc or other
> libraries, crashing is generally considered an entirely acceptable
> failure mode.

There are two scenarios when rebuilding the environment for the first
time that I am using warnx/errx:
1. The user supplied an environ where a variable is missing an "=value"
    portion.
2. The code I wrote did not work as expected.

Is your thought that since the API has no means (specification-wise) to
inform the user that something is wrong that an exit should/may be
performed?  To stick with the specification, I see why errx() would be
desired.  In addition, malloc() can handle a double-free and still run
correctly.  For environ, if it is incorrect, the code will never allow
*env() to succeed.

Sean
-- 
sean-freebsd at farley.org