Why no segmentation fault

[Eric Sosman]

Mark McIntyre wrote On 03/27/06 16:37,:

I think you may have this backwards, since I recall being able to
compile perfectly normal C code with VAX-C, but its at least five
years since I last programmed on a Vax so...

<off-topic>

Sherman, set the Wayback Machine for the mid-1980's.

VMS "condition codes" were/are structured values with
multiple fields and sub-fields packed into thirty-two bits.
The low-order three bits were the "severity," and five of
the eight possible values were actually used: SUCCESS,
INFORMATIONAL, WARNING, ERROR, and FATAL. The lowest-order
bit summarized matters even more crudely: odd values were
successful (SUCCESS and INFORMATIONAL), while even values
indicated failures (WARNING, ERROR, FATAL).

Early on, the value passed to exit() or returned from
main() was simply treated as a VMS condition code, and was
handed straight back to the invoker unaltered. Alas, this
meant that C programs ported from Unix usually seemed to
fail when they succeeded and succeed when they failed, since
the exit statuses zero and one mapped to failure and success
instead of the other way around. For a while DEC tried to
persuade people to use native VMS condition codes (arguably
the Right Thing To Do as part of a port), but eventually
they threw in the towel and patched the VAXC library so it
mapped zero to one and one to zero while leaving other
status values unchanged (so a VMS-aware program could use
them to report more elaborate status information).

Once the ANSI Standard appeared, VAXC gained a few
ANSIfications (although it never fully complied to the
Standard; DEC brought out a completely new DECC compiler
and library as their Standard-compliant implementation.)
Among the ANSIisms were the <stdlib.h> header ("header,"
not "header file") and the EXIT_SUCCESS and EXIT_FAILURE
macros. These did not expand to 0 and 1 a la Unix, nor to
1 and 0 a la pre-surrender VMS, but to full-fledged VMS
condition codes, complete with Facility, Message, and
Severity fields.

Up-thread, Santosh asked rhetorically

Would it not be absurd for an implementation to return
"status" values of different kinds for exit(0) and
exit(EXIT_SUCCESS), [...]

Well, Santosh, VAXC on VMS was an implementation that
actually did so, and although VMS had many peculiarities
I don't think this really counts as one of them. An exit
status of zero (after translation to one) meant "Some kind
of success status emanating from an unspecified component
of the system," while EXIT_SUCCESS meant "Successful
completion of a VAXC program."

Mark McIntyre says he programmed in "VAX-C" some five
years ago, which seems rather recent for such an elderly
implementation. It's possible, I guess -- maybe he was
working on elderly code -- but DECC would have been a
more likely choice, certainly a more likely choice for
new code. In the days (considerably more than five years
agone) when I worked on VAXen, we never really transitioned
the existing code from VAXC to DECC -- in part because not
all our platforms had usable ANSI-conforming compilers,
and we didn't want to undertake the K&R-to-ANSI transition
until there was a good chance of bringing it off. And as
it turned out, "until" never came: That PPOE went into a
prolonged and painful death spiral, and nowadays exists
only as a brand name some other company bought.

</off-topic>

 

[Jordan Abel]

There are different kinds of success, though, aren't there?


eg
exit (success-and-missed-object-in-water)
exit (success-and-beached-on-iceberg)
exit(success-but-ship-sank-anyway-due-to-outside-factors)


I strongly suspect VMS lets you have a forest of possible different
"it worked" results.
0 = VMS-I-SUCCESS successful programme termination
64 = VMS-I-SUCCESS successful cluster shutdown
128 = VMS-I-SUCCESS successfully ejected the warp core

But why use a different one for 0 than for EXIT_SUCCESS?

 

[Keith Thompson]

Sherman, set the Wayback Machine for the mid-1980's.

VMS "condition codes" were/are structured values with
multiple fields and sub-fields packed into thirty-two bits.
The low-order three bits were the "severity," and five of
the eight possible values were actually used: SUCCESS,
INFORMATIONAL, WARNING, ERROR, and FATAL. The lowest-order
bit summarized matters even more crudely: odd values were
successful (SUCCESS and INFORMATIONAL), while even values
indicated failures (WARNING, ERROR, FATAL).

Early on, the value passed to exit() or returned from
main() was simply treated as a VMS condition code, and was
handed straight back to the invoker unaltered. Alas, this
meant that C programs ported from Unix usually seemed to
fail when they succeeded and succeed when they failed, since
the exit statuses zero and one mapped to failure and success
instead of the other way around. For a while DEC tried to
persuade people to use native VMS condition codes (arguably
the Right Thing To Do as part of a port), but eventually
they threw in the towel and patched the VAXC library so it
mapped zero to one and one to zero while leaving other
status values unchanged (so a VMS-aware program could use
them to report more elaborate status information).

Once the ANSI Standard appeared, VAXC gained a few
ANSIfications (although it never fully complied to the
Standard; DEC brought out a completely new DECC compiler
and library as their Standard-compliant implementation.)
Among the ANSIisms were the <stdlib.h> header ("header,"
not "header file") and the EXIT_SUCCESS and EXIT_FAILURE
macros. These did not expand to 0 and 1 a la Unix, nor to
1 and 0 a la pre-surrender VMS, but to full-fledged VMS
condition codes, complete with Facility, Message, and
Severity fields.

On OpenVMS 6.2, EXIT_SUCCESS is 0 and EXIT_FAILURE is 268435458
(that's 0x10000002) under DECC. Under VAXC, EXIT_SUCCESS is 0 and
EXIT_FAILURE is 2.

As I recall, the system maps exit(0) to a successful status, but it
*doesn't* map exit(1) to an unsuccessful status; I've seen VMS C
programs that use "exit(1)", but that appear to have run successfully.

Up-thread, Santosh asked rhetorically

Would it not be absurd for an implementation to return
"status" values of different kinds for exit(0) and
exit(EXIT_SUCCESS), [...]

Well, Santosh, VAXC on VMS was an implementation that
actually did so, and although VMS had many peculiarities
I don't think this really counts as one of them. An exit
status of zero (after translation to one) meant "Some kind
of success status emanating from an unspecified component
of the system," while EXIT_SUCCESS meant "Successful
completion of a VAXC program."

Since EXIT_SUCCESS==0, exit(EXIT_SUCCESS) and exit(0) both mean the
same thing (at least on the VMS systems I've used).

Mark McIntyre says he programmed in "VAX-C" some five
years ago, which seems rather recent for such an elderly
implementation. It's possible, I guess -- maybe he was
working on elderly code -- but DECC would have been a
more likely choice, certainly a more likely choice for
new code. In the days (considerably more than five years
agone) when I worked on VAXen, we never really transitioned
the existing code from VAXC to DECC -- in part because not
all our platforms had usable ANSI-conforming compilers,
and we didn't want to undertake the K&R-to-ANSI transition
until there was a good chance of bringing it off. And as
it turned out, "until" never came: That PPOE went into a
prolonged and painful death spiral, and nowadays exists
only as a brand name some other company bought.

VAXC does at least recognize prototype, but, among other things, it
still recognizes the old "-=" assignment operators. For example the
statement
x=-1;
produces an informational message:

%CC-I-ANACHRONISM, The "=-" operator is an obsolete form,
and may not be portable.

but it then decrements x rather than assigning the value -1.

 

[Eric Sosman]

Keith Thompson wrote On 03/27/06 18:13,:
Thanks for the corrections, Keith. Some of my memory
bits have been abraded by alpha particles over the past
twenty years, and the details dwindledwindledwindle away.

 

[Keith Thompson]

Keith Thompson wrote On 03/27/06 18:13,:

Thanks for the corrections, Keith. Some of my memory
bits have been abraded by alpha particles over the past
twenty years, and the details dwindledwindledwindle away.

The vax particles are much more abrasive than the alpha particles.

 

[Eric Sosman]

Keith Thompson wrote On 03/27/06 18:13,:

[...]


Sherman, set the Wayback Machine for the mid-1980's.

Thanks for the corrections, Keith. Some of my memory
bits have been abraded by alpha particles over the past
twenty years, and the details dwindledwindledwindle away.

The vax particles are much more abrasive than the alpha particles.

Yeah, but the alpha particles move so much faster ...

 

[Joe Wright]

Keith Thompson wrote On 03/27/06 18:13,:

[...]


Sherman, set the Wayback Machine for the mid-1980's.

Thanks for the corrections, Keith. Some of my memory
bits have been abraded by alpha particles over the past
twenty years, and the details dwindledwindledwindle away.

The vax particles are much more abrasive than the alpha particles.

Yeah, but the alpha particles move so much faster ...

I thought Chuck Falconer was the old dog around here. When did you write
"hello, world\n" in C the first time? Eric? Keith?

When was the last time anybody made a mark on VAXC? Did anything VAX
survive the Compaq buy of DEC? (and now the HP buy of Compaq?)

Is this Topical here? (I have to ask so that this post is topical.)

I wrote "hello, world\n" in 1986 but I copied it out of an eight year
old paperback.

I still have the paperback.

 

[Eric Sosman]

Keith Thompson wrote On 03/27/06 18:13,:

[...]


Sherman, set the Wayback Machine for the mid-1980's.


Thanks for the corrections, Keith. Some of my memory
bits have been abraded by alpha particles over the past
twenty years, and the details dwindledwindledwindle away.



The vax particles are much more abrasive than the alpha particles.

Yeah, but the alpha particles move so much faster ...

I thought Chuck Falconer was the old dog around here. When did you write
"hello, world\n" in C the first time? Eric? Keith?

Chuck and I can bark with the best, but my bite is
less fearsome than it used to be ... I first wrote C in,
in, well, it must have been 1978 or 9. First project was
a communications controller for a vector-graphics terminal,
and a right mess I made of it, too.

Every so often a guy named Dennis posts here, with a
preposterous claim of having even earlier C experience.
If one were so gullible as to take his boast at face value,
even the oldest dogs would rate as mere puppies.

When was the last time anybody made a mark on VAXC? Did anything VAX
survive the Compaq buy of DEC? (and now the HP buy of Compaq?)

I can date my last VAXC compilation fairly precisely:
it was in the Summer of 1998, when my PPOE paid me to work
a few nights getting a patch out for them. Seems there was
no one left there who could spell "VAX," but a substantial
number of customers with support contracts ...

Is this Topical here? (I have to ask so that this post is topical.)

As long as you use proper quoting conventions, include
proper attributions, don't top-post, and can still find the
SHIFT key, you're topical. (sorry i meant ur kewl.)

I wrote "hello, world\n" in 1986 but I copied it out of an eight year
old paperback.

I still have the paperback.

So do I: One of the two best programming language texts
I've ever read. Never got around to reading the second
edition, though.

 

[Keith Thompson]

Keith Thompson wrote On 03/27/06 18:13,:

[...]


Sherman, set the Wayback Machine for the mid-1980's.

Thanks for the corrections, Keith. Some of my memory
bits have been abraded by alpha particles over the past
twenty years, and the details dwindledwindledwindle away.


The vax particles are much more abrasive than the alpha particles.

Yeah, but the alpha particles move so much faster ...

I thought Chuck Falconer was the old dog around here. When did you
write "hello, world\n" in C the first time? Eric? Keith?

My first exposure to C was in 1981, on a VAX 11/780 running BSD Unix
(sdcsvax).

When was the last time anybody made a mark on VAXC? Did anything VAX
survive the Compaq buy of DEC? (and now the HP buy of Compaq?)

At my last job, late 1997 to early 1999, I worked on a system,
programmed in C, that ran on a cluster of VMS systems, both VAX and
Alpha. We had VAXC only on the VAX systems, and DECC on both. (I
advocated dropping any use of VAXC.) (Compaq's buyout of DEC happened
while I was there.) Rumor says they're now using just Alpha systems,
but I haven't kept in touch.

 

[santosh]

Mark McIntyre wrote On 03/27/06 16:37,:

<off-topic>

Sherman, set the Wayback Machine for the mid-1980's.

VMS "condition codes" were/are structured values with
multiple fields and sub-fields packed into thirty-two bits.
The low-order three bits were the "severity," and five of
the eight possible values were actually used: SUCCESS,
INFORMATIONAL, WARNING, ERROR, and FATAL. The lowest-order
bit summarized matters even more crudely: odd values were
successful (SUCCESS and INFORMATIONAL), while even values
indicated failures (WARNING, ERROR, FATAL).

Early on, the value passed to exit() or returned from
main() was simply treated as a VMS condition code, and was
handed straight back to the invoker unaltered. Alas, this
meant that C programs ported from Unix usually seemed to
fail when they succeeded and succeed when they failed, since
the exit statuses zero and one mapped to failure and success
instead of the other way around.

Couldn't the C library for VAX be modified to perform the conversion
before passing the value to the system? Generally it's the C library,
or any other abstraction layer in between, that has to cover-up the
quirks of the host system.

Up-thread, Santosh asked rhetorically

Would it not be absurd for an implementation to return
"status" values of different kinds for exit(0) and
exit(EXIT_SUCCESS), [...]

Well, Santosh, VAXC on VMS was an implementation that
actually did so, and although VMS had many peculiarities
I don't think this really counts as one of them. An exit
status of zero (after translation to one) meant "Some kind
of success status emanating from an unspecified component
of the system," while EXIT_SUCCESS meant "Successful
completion of a VAXC program."

Okay, I conceed that exotic systems like VMS might accept numerous
return values as condition codes. But still, 0 and EXIT_SUCCESS
*should* mean the same thing. If not then the system/library is
second-guessing the programmer. Other implementation specified macros
could be defined for indicating various types of sucesses and failures
but EXIT_SUCCESS and 0 should mean the same thing.

The host environment can assign any meaning to any particular return
value as it is not constrained by the C standard, but the C library
should ensure that 0 and EXIT_SUCCESS, as well as EXIT_FAILURE, are
mapped to the host recognised values for successful termination and
unsuccessful termination in the respective cases.

 

[santosh]

Keith Thompson wrote On 03/27/06 18:13,:

Thanks for the corrections, Keith. Some of my memory
bits have been abraded by alpha particles over the past
twenty years, and the details dwindledwindledwindle away.

More likely by free radicals

 

[Keith Thompson]

Eric Sosman wrote: [...]
Okay, I conceed that exotic systems like VMS might accept numerous
return values as condition codes. But still, 0 and EXIT_SUCCESS
*should* mean the same thing. If not then the system/library is
second-guessing the programmer. Other implementation specified macros
could be defined for indicating various types of sucesses and failures
but EXIT_SUCCESS and 0 should mean the same thing.

The host environment can assign any meaning to any particular return
value as it is not constrained by the C standard, but the C library
should ensure that 0 and EXIT_SUCCESS, as well as EXIT_FAILURE, are
mapped to the host recognised values for successful termination and
unsuccessful termination in the respective cases.

IMHO, a cleaner solution would have been for the C standard to specify
only EXIT_SUCCESS and EXIT_FAILURE as portable exit codes, leaving the
behavior of both 0 and 1 unspecified.

In the Unix world that gave birth to C, 0 means success, and non-zero
(particularly 1) means failure. The C standard chose to require 0 to
mean success on all systems, which, as we've seen, caused problems for
VMS.

On the other hand, if only EXIT_SUCCESS and EXIT_FAILURE were defined,
then almost all programs would have to have a "#include <stdlib.h>" to
see the definitions -- and all pre-ANSI code would have become
non-portable.

 

[CBFalconer]

Chuck and I can bark with the best, but my bite is
less fearsome than it used to be ... I first wrote C in,
in, well, it must have been 1978 or 9. First project was
a communications controller for a vector-graphics terminal,
and a right mess I made of it, too.

Every so often a guy named Dennis posts here, with a
preposterous claim of having even earlier C experience.
If one were so gullible as to take his boast at face value,
even the oldest dogs would rate as mere puppies.
.... snip ...


So do I: One of the two best programming language texts
I've ever read. Never got around to reading the second
edition, though.

Just a muffled woof here. I wonder if several books are going to
show up when and if I get around to unpacking after my move. K&R1
is one, TAOCP is another, and so is Aho.

I ignored C for a long time, and concentrated on Pascal.
Eventually I grudgingly conceded there might be something to it,
after being forced to use it about 10 years ago. However I
maintain that my C is much better for having used Pascal.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[CBFalconer]

.... snip ...

IMHO, a cleaner solution would have been for the C standard to
specify only EXIT_SUCCESS and EXIT_FAILURE as portable exit codes,
leaving the behavior of both 0 and 1 unspecified.

In the Unix world that gave birth to C, 0 means success, and
non-zero (particularly 1) means failure. The C standard chose to
require 0 to mean success on all systems, which, as we've seen,
caused problems for VMS.

On the other hand, if only EXIT_SUCCESS and EXIT_FAILURE were
defined, then almost all programs would have to have a "#include
<stdlib.h>" to see the definitions -- and all pre-ANSI code would
have become non-portable.

No, those definitions could (and IMO should) have been available
via all of stdio, stddef, or stdlib.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Eric Sosman]

Eric Sosman wrote:
[...]

Okay, I conceed that exotic systems like VMS might accept numerous
return values as condition codes. But still, 0 and EXIT_SUCCESS
*should* mean the same thing. If not then the system/library is
second-guessing the programmer. Other implementation specified macros
could be defined for indicating various types of sucesses and failures
but EXIT_SUCCESS and 0 should mean the same thing.

The host environment can assign any meaning to any particular return
value as it is not constrained by the C standard, but the C library
should ensure that 0 and EXIT_SUCCESS, as well as EXIT_FAILURE, are
mapped to the host recognised values for successful termination and
unsuccessful termination in the respective cases.

IMHO, a cleaner solution would have been for the C standard to specify
only EXIT_SUCCESS and EXIT_FAILURE as portable exit codes, leaving the
behavior of both 0 and 1 unspecified.

In the Unix world that gave birth to C, 0 means success, and non-zero
(particularly 1) means failure. The C standard chose to require 0 to
mean success on all systems, which, as we've seen, caused problems for
VMS.

I don't think it was the Standard's decree that caused
the problem. The Standard simply recognized a convention
that was already widely used in existing C programs, and it
was that pre-existing convention that fit poorly with VMS'
structured condition codes.

On the other hand, if only EXIT_SUCCESS and EXIT_FAILURE were defined,
then almost all programs would have to have a "#include <stdlib.h>" to
see the definitions -- and all pre-ANSI code would have become
non-portable.

Almost every program needs <stdlib.h> anyhow, because
almost every program uses malloc() and friends. Note that
<stdlib.h> is an invention of the Committee, a header not
found (or not widely found) in pre-Standard C and hence not
a header existing code would have #included.

(Maybe "needs" is too strong. Lots of pre-ANSI code
declared `char *malloc()' and cast the result, and this
worked fine. Under ANSI rules it wasn't quite right, but
implementors had a strong incentive to avoid breaking old
code gratuitously -- so they made sure that `void*' and
`char*' functions returned values in the same register,
that `int' and `size_t' arguments were passed to functions
in the same way, and so on. Perhaps I should have written
"needs (for maximal cleanliness)."

 

[Eric Sosman]

CBFalconer wrote On 03/28/06 07:23,:

[...]
I ignored C for a long time, and concentrated on Pascal.
Eventually I grudgingly conceded there might be something to it,
after being forced to use it about 10 years ago. However I
maintain that my C is much better for having used Pascal.

Using multiple languages seems to be good for
programmers. I never liked Pascal much (I only used
the Borland dialect and only on an eight-bit machine),
but found that exposure to Lisp improved my C.

That's why I think the people who ask "Which
language is best?" are misguided (and those who
claim "Language X Rulez!" or "Language Y Sucks!"
are even more so). Use several languages and get
to know their character; even if you never write
anything but PL/I it will be helpful to have known
Snobol.

 

[Richard Bos]

198...7, I think. Perhaps '88. Not from a book, from a set of text files
that taught me absolutely _dreadful_ habits. After which I did not get
around to writing anything serious for many years, so in terms of _real_
experience I'm much more of a newbie than you.

I ignored C for a long time, and concentrated on Pascal.
Eventually I grudgingly conceded there might be something to it,
after being forced to use it about 10 years ago. However I
maintain that my C is much better for having used Pascal.

Oh, definitely. I learned Pascal just before I learned C, then went back
to Pascal because I had better texts for it, and that allowed me to at
least learn _some_ decent programming when I went back to BASIC and C.

Richard

 

[Mark McIntyre]

But why use a different one for 0 than for EXIT_SUCCESS?

because the OS expects it?

Mark McIntyre

 

[Mark McIntyre]

Keith Thompson wrote On 03/27/06 18:13,:

[...]

Sherman, set the Wayback Machine for the mid-1980's.

Thanks for the corrections, Keith. Some of my memory
bits have been abraded by alpha particles over the past
twenty years, and the details dwindledwindledwindle away.

The vax particles are much more abrasive than the alpha particles.

Yeah, if you had a shower of vaxen running through your brain, you
could seriously expect it to be scrambled...

Mark McIntyre

 

[Jordan Abel]

because the OS expects it?

Then the same value the OS expects for EXIT_SUCCESS should also be
returned to the OS on exit(0), because _programmers_ don't expect there
to be a difference