exit()

[Nick Keighley]

The core problem underlying all of this - is the fact that the shell treats
a return value of 0 as "TRUE" and anything else (i.e., non-zero) as FALSE..
Which is the exact opposite of what C (and most other programming languages)
do.  Hence the confusion.  Digging further, what underlies that is a basic
intuitive feeling that "TRUE" should be "good" and FALSE "bad", which, I
think, corresponds with most people's basic feelings about the Universe.

Interestingly enough, the first platform I ever used that used the concept
of TRUE/FALSE to indicate error/success, did so in that order - namely,
TRUE == error and FALSE == success.  Counterintuitive this was,but it got
the job done nicely.

Finally, note that the Windows API mostly follows the model that 0 ==failure,
1 (although this is usually documented as "non-zero")  == success, because
this is what most people (unless they've come from a Unix background) expect
and are comfortable with, even though it is technically less efficient.

annoyingly I sometimes see code that returns a bool result for such a
convention. (I'm not sure if MS do this though)

ah yes this is what I was thinking:-

************************************
BOOL WINAPI DeleteFile(
_In_ LPCTSTR lpFileName
);

Return value

If the function succeeds, the return value is nonzero.

If the function fails, the return value is zero (0). To get extended
error information, call GetLastError.
************************************

A sane convention I just wish they hadn't called it BOOL!

<snip>

 

[Nick Keighley]

Lisp treats everything as a boolean, but its sole false value is "nil" aka
the empty list, while everything else (including integer zero) is true.

scheme (which is sort of lispy) uses special values #t and #f.
Anything that isn't #f is true.

 

[Nick Keighley]

This is typical of some Windows functions:

"If the function succeeds, the return value is nonzero.

If the function fails, the return value is zero. To get extended error
information, call GetLastError."

That seems reasonable enough;

I quite like it. It seems to be used very consistently- which helps. I
must admit in my own APIs I use Retval as the return type and it
returns either OK (usually zero though I don't rely on it) or an error
code.

often I don't care about the failure,

seriously? Why do you think MS go to the troble of returning an error?
I wrapper every windows call

if (WindowCall (hUngArian_t dodah) = -1)
window_error ("WindowCall");

and window_error does the GetLastError and translates it into a string
and then throws (that's a C++ error handling thingy)

and if I
do, what am I going to do about the hundreds of possible error codes
at the point of the call?

nuffink usually. Occaisionally there is some recovery strategy for
particular errors.

 

[BartC]

scheme (which is sort of lispy) uses special values #t and #f.
Anything that isn't #f is true.

If 'true' relates to success, and 'false' to failure, then that's the
opposite of what is proposed in this thread by those talking about multiple
failure codes.

C also uses multiple 'true' values.

 

[BartC]

seriously? Why do you think MS go to the troble of returning an error?

Sometimes the specific error is only of interest at a certain level.

I wrapper every windows call

if (WindowCall (hUngArian_t dodah) = -1)
window_error ("WindowCall");

and window_error does the GetLastError and translates it into a string
and then throws (that's a C++ error handling thingy)

Which is pretty much what I suggest later:

 

[Keith Thompson]

If 'true' relates to success, and 'false' to failure, then that's the
opposite of what is proposed in this thread by those talking about multiple
failure codes.

C also uses multiple 'true' values.

That's the point: true and false are *not* the same as success and
failure, respectively.

For a function that returns zero for success and non-zero for
failure, the question being answered is not "Did this succeed?";
it's "What went wrong?", with 0 as a special case meaning "Nothing".

The way to express "Did this call to func() succeed?" is not
`func()`, but `func() == 0`.

I understand and agree that it would be more intuitive if it were
the other way around. The convention is the way it is simply because
it's more useful to have multiple error codes than to have multiple
success codes.

In a language that doesn't conflate numbers and booleans the way C does,
this confusion doesn't arise. But once you accept the convention for
what it is, it's not that hard to deal with.

 

[Phil Carmody]

If 'true' relates to success, and 'false' to failure, then that's the
opposite of what is proposed in this thread ...

.... who were talking about C.

C isn't LISP.

I am not able rightly to apprehend the kind of confusion of
ideas that could provoke such a conflation

Phil

 

[Keith Thompson]

... who were talking about C.

C isn't LISP.

I am not able rightly to apprehend the kind of confusion of
ideas that could provoke such a conflation

Well, there is some similarity. Both C and Scheme have a
more-or-less unique "false" value: #f for Scheme, and 0 for C
(different kinds of zeros for different types, and only for scalars,
but ...), with all other values being considered "true".

This is in contrast to languages (like Pascal and Ada, for example) in
which conditions can only be of a unique Boolean type with exactly two
distinct values.

The confusion, I think, is caused by the conflation of truth and
falsehood with success and failure, respectively. That's certainly
misleading in C, which has a strong convention of functions
returning 0 for success and non-0 for failure. It's probably equally
misleading in Scheme and other Lisps.

 

[Shao Miller]

The confusion, I think, is caused by the conflation of truth and
falsehood with success and failure, respectively. That's certainly
misleading in C, which has a strong convention of functions
returning 0 for success and non-0 for failure. It's probably equally
misleading in Scheme and other Lisps.

Agreed. As someone already mentioned, it depends on the question.

void * ptr = malloc(12);
/* Did malloc yield an invalid pointer? */
if (!ptr)
/* ... */

"fail" and "succeed" are shortcuts that seem subjective. 'malloc' might
fail to yield a null pointer value or succeed to give one.

 

[Phil Carmody]

Well, there is some similarity. Both C and Scheme have a
more-or-less unique "false" value: #f for Scheme, and 0 for C
(different kinds of zeros for different types, and only for scalars,
but ...), with all other values being considered "true".

This is in contrast to languages (like Pascal and Ada, for example) in
which conditions can only be of a unique Boolean type with exactly two
distinct values.

The confusion, I think, is caused by the conflation of truth and
falsehood with success and failure, respectively. That's certainly
misleading in C, which has a strong convention of functions
returning 0 for success and non-0 for failure. It's probably equally
misleading in Scheme and other Lisps.

Very true. But I do consider LISP to be a language far less oriented towards
returning status values. Then again, I always programmed it as a fairly pure
funtional language. C's far more side-effect oriented, and needs those
status values everywhere, it never just returns the acted-upon thing in the
same way LISP code so often does.

Phil

 

[88888 Dihedral]

Phil Carmodyæ–¼ 2013å¹´3月15日星期五UTC+8上åˆ10時56分47秒寫é“：LISP is a small language that was designed to be used with slow jumps
and fast stack operations in 195X-196X of the HW at that era.

With the advance of technologies of mass-productions of mico-processors
and so many teams could work out CPUs with different instruction sets,
then that was the reason to call for a portable assembly language,
i.e. c, in the 197X-199x.

 

[Ian Collins]

damercer2850 wrote:

<stuff>

These random giganews posts appear to be pooing up all over Usenet.