[Nut-upsdev] Re: [Nut-upsuser] Problem after reboot

[Arjen de Korte]

> The reason I like fatal_with_errno() is because it is
> self-documenting; if someone has not read developers.txt recently,
> they might not remember that there is a difference between fatal() and
> fatalx(). Typing fatal_with_errno() will serve as a useful reminder.

Indeed.

> There is no similar benefit to typing fatal_without_errno(), so I had
> not proposed to change it for that reason.

Fully agreed. In retrospect, my suggestion to add '-without-errno' makes
no sense at all, in the same sense it doesn't add anything to append
'-without-whatever' to a function. Never mind, I should remember to think
before I type... ;-)

> Ideally the function currently called fatalx() should just be called
> fatal(), since the "without errno" is what one would assume to be the
> default behavior anyway. However, renaming it to fatal() would lead to
> too much confusion, since a function by that name still exists in older
> versions and branches.

Agreed, we don't want to confuse developers more than we already do.

>> It seems that our posts crossed. I just proposed to keep the names as
>> they are and just let fatal() behave as fatalx() when errno is zero, to
>> prevent printing "success" where the action taken (aborting the program)
>> clearly means something is very wrong. As far as I'm concerned, that
>> should be enough.
> This is clearly a sensible thing to do, so that users don't get
> confused if programmers screwed up. However, it is only a damage
> control measure in case fatal() is called improperly. There is no
> guarantee that errno==0 if fatal() is called after some failure that
> did not set errno. In that situation, errno might well be non-0, because
> some previous (non-fatal) system call set it.

There is nothing we can do for the latter case, other than documenting
such behaviour and recommending to handle errors in the calling function,
rather than relying on strerror() to provide useful output.

The benefit of a locale dependent error message (like using 'errno' here)
doesn't always mean that the resulting output will make sense to an end
user. In that case it may be better to handle it yourself (I'd prefer
that, at least for the most common configuration mistakes).

Arjen