473,289 Members | 1,961 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,289 software developers and data experts.

Why no segmentation fault

Hi,

I'm wondering why this program does not crash with a segmentation
fault:

#include <malloc.h>
#include <string.h>
#include <stdio.h>

int main()
{
char *array;

array = (char*)malloc(10 * sizeof(char) );
if ( array == NULL )
exit( 0 );

strcpy( array, "11223456789\0");

printf( "\narray[11]: %c\n", array[11] )

return 0;
}

I allocate space for 10 characters on the system heap and then copy
a string of size 12 into the allocated space. Why does the program not
crash?
My understanding was so far:
malloc request some new free space on the system heap. So, first the
program memory manager is consulted to check if it is already assigned
some free space by the operating system that might be suitable for the
malloc request. If so, this memory segment is used. Otherwise, the
request is directed to the OS that provides some new free memory that
is now assigned to this program (process) and used for the malloc memory
allocation. However, when I call "strcpy( array, "11223456789\0")" I
write the first 10 characters to the allocated memory area.The
remaining 2 characters exceed the memory area I was granted access to
and are tried to be written to memory I have no write access to. That
illegal memory access should be noticed by the OS that terminates the
program with a segmentation fault.

Furthermore, my printf should also crash the program since I
illegally attempt to read from memory I have no access to.

Thank you.

Chris

Mar 26 '06 #1
59 2821
On 2006-03-26, Christian Christmann <pl*****@yahoo.de> wrote:
Hi,

I'm wondering why this program does not crash with a segmentation
fault:

#include <malloc.h>
#include <string.h>
#include <stdio.h>

int main()
{
char *array;

array = (char*)malloc(10 * sizeof(char) );
if ( array == NULL )
exit( 0 );

strcpy( array, "11223456789\0");

printf( "\narray[11]: %c\n", array[11] )

return 0;
}


There is no guarentee that HW will catch all such illegal memory
accesses. There are not (always) runtime checks in languages to check
for out of bounds : it is one of the efficiencies of C that it assumes
the programmer will do the necessary bounds checks. Writing over
"illegal" memory is, I believe, "undefined" but most certainly bad
practice and most certainly will lead to nasties cropping up at a
later date if nto immediately.

I velieve it is legal to reference one unit of storage past the
"malloc"ed area, but I'm sure someone will provide more info on that.

Mar 26 '06 #2
Christian Christmann wrote:
Hi,

I'm wondering why this program does not crash with a segmentation
fault:

#include <malloc.h>
Non-standard header. Should include stdlib.h instead.
#include <string.h>
#include <stdio.h>

int main()
A better form is int main(void)
{
char *array;

array = (char*)malloc(10 * sizeof(char) );
Don't cast the return value of malloc. A better form of the above
statement is:
array = malloc(10 * sizeof *array);

This also has the side effect that if you ever change the base type,
(char here), you won't have to modify this statement.
if ( array == NULL )
exit( 0 );
exit(EXIT_SUCCESS); or exit(EXIT_FAILURE) would be more portable though
zero is always a portable return value to indicate successfull
termination.
strcpy( array, "11223456789\0");

printf( "\narray[11]: %c\n", array[11] )

return 0;
}

I allocate space for 10 characters on the system heap and then copy
a string of size 12 into the allocated space. Why does the program not
crash?
My understanding was so far:
malloc request some new free space on the system heap. So, first the
program memory manager is consulted to check if it is already assigned
some free space by the operating system that might be suitable for the
malloc request. If so, this memory segment is used. Otherwise, the
request is directed to the OS that provides some new free memory that
is now assigned to this program (process) and used for the malloc memory
allocation. However, when I call "strcpy( array, "11223456789\0")" I
write the first 10 characters to the allocated memory area.The
remaining 2 characters exceed the memory area I was granted access to
and are tried to be written to memory I have no write access to. That
illegal memory access should be noticed by the OS that terminates the
program with a segmentation fault.

Furthermore, my printf should also crash the program since I
illegally attempt to read from memory I have no access to.


Your program writes past the end of the array and doing so, invokes
undefined behaviour. Wether it eventually crashes or not is
implementation defined. In any case, anything can happen as per the C
standard. It might apparently continue running normally, (like your
case, which could be because, your library memory manager reserved more
memory as a part of your process, and that they just happen to lie past
your allocated chunk.), or it might misbehave later or dump core
immediately.

It doesn't matter. Once you've created undefined behaviour, anything
might happen.

Mar 26 '06 #3
santosh wrote:

Your program writes past the end of the array and doing so, invokes
undefined behaviour. Wether it eventually crashes or not is
implementation defined. [...]


<pedantry>

It's not even implementation-defined; the implementation
has no obligation to document the consequences. Undefined is
undefined, and there's an end on't.

</pedantry>

--
Eric Sosman
es*****@acm-dot-org.invalid
Mar 26 '06 #4
Eric Sosman wrote:
santosh wrote:
Your program writes past the end of the array and doing so, invokes
undefined behaviour. Wether it eventually crashes or not is
implementation defined. [...]


<pedantry>
It's not even implementation-defined; the implementation
has no obligation to document the consequences. Undefined is
undefined, and there's an end on't.
</pedantry>


Thanks pedantic point duly noted and filed!

Mar 26 '06 #5
On 26 Mar 2006 10:03:10 -0800, santosh <sa*********@gmail.com> wrote:
Christian Christmann wrote:

....
{
char *array;

array = (char*)malloc(10 * sizeof(char) );


Don't cast the return value of malloc. A better form of the above
statement is:
array = malloc(10 * sizeof *array);

This also has the side effect that if you ever change the base type,
(char here), you won't have to modify this statement.


Yes; casting malloc()'s return value became obsolete when void * was
introduced, some twenty years ago.

As a side note, typing "sizeof(char)" is pointless, since its value is, by
definition, 1.

/Jorgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
Mar 26 '06 #6
"santosh" <sa*********@gmail.com> writes:
Christian Christmann wrote: [...] This also has the side effect that if you ever change the base type,
(char here), you won't have to modify this statement.
if ( array == NULL )
exit( 0 );


exit(EXIT_SUCCESS); or exit(EXIT_FAILURE) would be more portable though
zero is always a portable return value to indicate successfull
termination.


exit(0) is exactly as portable as exit(EXIT_SUCCESS); both are defined
to return a status that indicates successful termination (though not
necessarily the same status).

But since this particular exit() is executed only on a failure of
malloc(), exit(EXIT_FAILURE) would make more sense. (Note that
exit(1), unlike exit(0), is *not* portable.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Mar 26 '06 #7
Keith Thompson wrote:
"santosh" <sa*********@gmail.com> writes:

<snip>
exit(EXIT_SUCCESS); or exit(EXIT_FAILURE) would be more portable though
zero is always a portable return value to indicate successfull
termination.


exit(0) is exactly as portable as exit(EXIT_SUCCESS); both are defined
to return a status that indicates successful termination (though not
necessarily the same status).


Err, don't you mean:
"...though not necessarily the same value."
above?

<snip>

Mar 26 '06 #8
"santosh" <sa*********@gmail.com> writes:
Keith Thompson wrote:
"santosh" <sa*********@gmail.com> writes:

<snip>
> exit(EXIT_SUCCESS); or exit(EXIT_FAILURE) would be more portable though
> zero is always a portable return value to indicate successfull
> termination.


exit(0) is exactly as portable as exit(EXIT_SUCCESS); both are defined
to return a status that indicates successful termination (though not
necessarily the same status).


Err, don't you mean:
"...though not necessarily the same value."
above?


No, I meant status. It's also true that it's not necessarily the same
value.

The standard says:

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.

EXIT_SUCCESS, EXIT_FAILURE, and 0 are values of type int that can be
passed to the exit() function. A "status" is a vaguely-defined thing
that's seen by the host environment; it isn't necessarily a value,
particularly an int value, in the sense used within a C program. (The
fact that parameter to exit() is also called "status" is potentially
confusing.)

If EXIT_SUCCESS==0, then presumably both exit(EXIT_SUCCESS) and
exit(0) return the same "status" to the environment. If
EXIT_SUCCESS!=0, then exit(EXIT_SUCCESS) and exit(0) may or may not
return the same "status" to the environment.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Mar 26 '06 #9
Keith Thompson wrote:
"santosh" <sa*********@gmail.com> writes:
Keith Thompson wrote:
exit(0) is exactly as portable as exit(EXIT_SUCCESS); both are defined
to return a status that indicates successful termination (though not
necessarily the same status).
Err, don't you mean:
"...though not necessarily the same value."
above?


No, I meant status. It's also true that it's not necessarily the same
value.

.... snip ...
If EXIT_SUCCESS==0, then presumably both exit(EXIT_SUCCESS) and
exit(0) return the same "status" to the environment. If
EXIT_SUCCESS!=0, then exit(EXIT_SUCCESS) and exit(0) may or may not
return the same "status" to the environment.


Okay, so both exit(0) and exit(EXIT_SUCCESS) need not return the same
"status" to the host environment although they both *indicate*
successful program termination. Got it now, just that your wording in
your first reply to me seemed contradictory.

Mar 26 '06 #10
santosh wrote:
Christian Christmann wrote:


<snip>
if ( array == NULL )
exit( 0 );


exit(EXIT_SUCCESS); or exit(EXIT_FAILURE) would be more portable though
zero is always a portable return value to indicate successfull
termination.


<snip>

As well as the comments others have made, exit(EXIT_SUCCESS) and
exit(EXIT_FAILURE) are no more portable than exit(0) since all three are
completely portable. Any other value and zero and I would have agreed.
However, in this case exit(EXIT_FAILURE) would have been far better
style since the program has failed.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
Mar 26 '06 #11
Richard G. Riley wrote:

<snip>
I velieve it is legal to reference one unit of storage past the
"malloc"ed area, but I'm sure someone will provide more info on that.


It is legal to create a pointer to one past the end, but it is not legal
to dereference that pointer.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
Mar 26 '06 #12
Keith Thompson wrote:
"santosh" <sa*********@gmail.com> writes:
Keith Thompson wrote:
exit(0) is exactly as portable as exit(EXIT_SUCCESS); both are defined
to return a status that indicates successful termination (though not
necessarily the same status).


Err, don't you mean:
"...though not necessarily the same value."
above?


No, I meant status. It's also true that it's not necessarily the same
value.

.... snip ...

Would it not be absurd for an implementation to return "status" values
of different kinds for exit(0) and exit(EXIT_SUCCESS), though the
standard does not disallow it? I mean, since both forms of exit() are
semantically identical, what would be gained in returning different
kinds of "status" values to the host environment? Are you aware of any
actual implementations that do this?

Mar 26 '06 #13
Flash Gordon <sp**@flash-gordon.me.uk> writes:
Richard G. Riley wrote:

<snip>
I velieve it is legal to reference one unit of storage past the
"malloc"ed area, but I'm sure someone will provide more info on that.


It is legal to create a pointer to one past the end, but it is not
legal to dereference that pointer.


"not legal" meaning that it invokes undefined behavior (the
implementation is not required to diagnose it).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Mar 26 '06 #14
"Christian Christmann" <pl*****@yahoo.de> wrote in message
news:44***********************@newsread2.arcor-online.net...
I'm wondering why this program does not crash with a segmentation
fault: .... Furthermore, my printf should also crash the program since I
illegally attempt to read from memory I have no access to.


Your program invokes undefined behavior. Undefined behavior can take many
forms, including doing nothing or doing exactly what the programmer
mistakenly expects.

Just because your machine traps on some undefined operations does not mean
it always will.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

*** Free account sponsored by SecureIX.com ***
*** Encrypt your Internet usage with a free VPN account from http://www.SecureIX.com ***
Mar 26 '06 #15
"santosh" <sa*********@gmail.com> writes:
Keith Thompson wrote:
"santosh" <sa*********@gmail.com> writes:
> Keith Thompson wrote:
>> exit(0) is exactly as portable as exit(EXIT_SUCCESS); both are defined
>> to return a status that indicates successful termination (though not
>> necessarily the same status).
>
> Err, don't you mean:
> "...though not necessarily the same value."
> above?


No, I meant status. It's also true that it's not necessarily the same
value.

... snip ...

Would it not be absurd for an implementation to return "status" values
of different kinds for exit(0) and exit(EXIT_SUCCESS), though the
standard does not disallow it? I mean, since both forms of exit() are
semantically identical, what would be gained in returning different
kinds of "status" values to the host environment? Are you aware of any
actual implementations that do this?


I suppose it would be absurd, but it would be perfectly valid. No, I
don't know of any implementations that do this. VMS is the obvious
candidate, but it defines EXIT_SUCCESS as 0, at least in the version I
have access to.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Mar 26 '06 #16
On Sun, 26 Mar 2006 19:33:40 +0200, Christian Christmann wrote:
Hi,

I'm wondering why this program does not crash with a segmentation fault:

#include <malloc.h>
#include <string.h>
#include <stdio.h>

int main()
{
char *array;

array = (char*)malloc(10 * sizeof(char) ); if ( array == NULL )
exit( 0 );

strcpy( array, "11223456789\0");

printf( "\narray[11]: %c\n", array[11] )

return 0;
}

I allocate space for 10 characters on the system heap and then copy a
string of size 12 into the allocated space. Why does the program not
crash?
My understanding was so far:
malloc request some new free space on the system heap. So, first the
program memory manager is consulted to check if it is already assigned
some free space by the operating system that might be suitable for the
malloc request. If so, this memory segment is used. Otherwise, the
request is directed to the OS that provides some new free memory that is
now assigned to this program (process) and used for the malloc memory
allocation. However, when I call "strcpy( array, "11223456789\0")" I
write the first 10 characters to the allocated memory area.The remaining
2 characters exceed the memory area I was granted access to and are
tried to be written to memory I have no write access to. That illegal
memory access should be noticed by the OS that terminates the program
with a segmentation fault.

Furthermore, my printf should also crash the program since I illegally
attempt to read from memory I have no access to.

Your malloc prolly allocates (multiples of) a fixed size block (a page?)
at a time from the OS from which it gives you a piece at a time every time
you malloc. If you've malloced it all up malloc will ask the OS for
more.... This is more efficient then having to ask the OS every time you
malloc a byte.

So even though you didn't get the memory from malloc, as long as you stay
inside the memory malloc allocated from the OS you wont cause a
segfault. The OS will happily let you fuck-up, as long a you do it in
your own home/process :)

Mark.

Mar 27 '06 #17
On 26 Mar 2006 13:02:10 -0800, in comp.lang.c , "santosh"
<sa*********@gmail.com> wrote:
Would it not be absurd for an implementation to return "status" values
of different kinds for exit(0) and exit(EXIT_SUCCESS), though the
standard does not disallow it?
There are different kinds of success, though, aren't there?
I mean, since both forms of exit() are
semantically identical, what would be gained in returning different
kinds of "status" values to the host environment?
eg
exit (success-and-missed-object-in-water)
exit (success-and-beached-on-iceberg)
exit(success-but-ship-sank-anyway-due-to-outside-factors)
Are you aware of any
actual implementations that do this?


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
:-)

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mar 27 '06 #18
Mark McIntyre <ma**********@spamcop.net> writes:
On 26 Mar 2006 13:02:10 -0800, in comp.lang.c , "santosh"
<sa*********@gmail.com> wrote:
Would it not be absurd for an implementation to return "status" values
of different kinds for exit(0) and exit(EXIT_SUCCESS), though the
standard does not disallow it?


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


Maybe. Some systems define only one kind of success (corresponding to
exit(0)).

[snip]
Are you aware of any
actual implementations that do this?


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
:-)


Actually, odd values denote success and even values denote errors
(which is why VMS has to translate exit(0) into a failure indication,
and exit(1) actually denotes success). But yes, there are many
different kinds of both success and failure in VMS (but no portable
way to specify them in C).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Mar 27 '06 #19
On Mon, 27 Mar 2006 21:13:46 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:
Actually, odd values denote success and even values denote errors
(which is why VMS has to translate exit(0) into a failure indication,
and exit(1) actually denotes success).


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...

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mar 27 '06 #20


Mark McIntyre wrote On 03/27/06 16:37,:
On Mon, 27 Mar 2006 21:13:46 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

Actually, odd values denote success and even values denote errors
(which is why VMS has to translate exit(0) into a failure indication,
and exit(1) actually denotes success).

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>

--
Er*********@sun.com

Mar 27 '06 #21
On 2006-03-27, Mark McIntyre <ma**********@spamcop.net> wrote:
On 26 Mar 2006 13:02:10 -0800, in comp.lang.c , "santosh"
<sa*********@gmail.com> wrote:
Would it not be absurd for an implementation to return "status" values
of different kinds for exit(0) and exit(EXIT_SUCCESS), though the
standard does not disallow it?


There are different kinds of success, though, aren't there?
I mean, since both forms of exit() are
semantically identical, what would be gained in returning different
kinds of "status" values to the host environment?


eg
exit (success-and-missed-object-in-water)
exit (success-and-beached-on-iceberg)
exit(success-but-ship-sank-anyway-due-to-outside-factors)
Are you aware of any
actual implementations that do this?


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?
Mar 27 '06 #22
Eric Sosman <Er*********@sun.com> writes:
[...]
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Mar 27 '06 #23


Keith Thompson wrote On 03/27/06 18:13,:
Eric Sosman <Er*********@sun.com> writes:
[...]
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.

--
Er*********@sun.com

Mar 27 '06 #24
Eric Sosman <Er*********@sun.com> writes:
Keith Thompson wrote On 03/27/06 18:13,:
Eric Sosman <Er*********@sun.com> writes:
[...]
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Mar 27 '06 #25
Keith Thompson wrote:
Eric Sosman <Er*********@sun.com> writes:
Keith Thompson wrote On 03/27/06 18:13,:
Eric Sosman <Er*********@sun.com> writes:
[...]
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 ...

--
Eric Sosman
es*****@acm-dot-org.invalid
Mar 28 '06 #26
Eric Sosman wrote:
Keith Thompson wrote:
Eric Sosman <Er*********@sun.com> writes:
Keith Thompson wrote On 03/27/06 18:13,:

Eric Sosman <Er*********@sun.com> writes:
[...]
> 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.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Mar 28 '06 #27
Joe Wright wrote:
Eric Sosman wrote:
Keith Thompson wrote:
Eric Sosman <Er*********@sun.com> writes:

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

> Eric Sosman <Er*********@sun.com> writes:
> [...]
>
>
>> 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.

--
Eric Sosman
es*****@acm-dot-org.invalid

Mar 28 '06 #28
Joe Wright <jo********@comcast.net> writes:
Eric Sosman wrote:
Keith Thompson wrote:
Eric Sosman <Er*********@sun.com> writes:

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

> Eric Sosman <Er*********@sun.com> writes:
> [...]
>
>
>> 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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Mar 28 '06 #29
Eric Sosman wrote:
Mark McIntyre wrote On 03/27/06 16:37,:
On Mon, 27 Mar 2006 21:13:46 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

Actually, odd values denote success and even values denote errors
(which is why VMS has to translate exit(0) into a failure indication,
and exit(1) actually denotes success).

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.


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.

Mar 28 '06 #30
Eric Sosman wrote:
Keith Thompson wrote On 03/27/06 18:13,:
Eric Sosman <Er*********@sun.com> writes:
[...]
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.


More likely by free radicals :)

Mar 28 '06 #31
"santosh" <sa*********@gmail.com> writes:
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Mar 28 '06 #32
Keith Thompson wrote:
"santosh" <sa*********@gmail.com> writes:
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
es*****@acm-dot-org.invalid
Mar 28 '06 #33
Eric Sosman wrote:
Joe Wright wrote:
Eric Sosman wrote:
.... snip ...
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.

.... snip ...
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.


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/>
Mar 28 '06 #34
Keith Thompson wrote:
.... 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/>
Mar 28 '06 #35
CBFalconer <cb********@yahoo.com> wrote:
Eric Sosman wrote:
Joe Wright wrote:

I thought Chuck Falconer was the old dog around here. When did
you write "hello, world\n" in C the first time? Eric? Keith? I wrote "hello, world\n" in 1986 but I copied it out of an eight
year old paperback. :-)

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
Mar 28 '06 #36


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.

--
Er*********@sun.com

Mar 28 '06 #37
On 27 Mar 2006 23:04:52 GMT, in comp.lang.c , Jordan Abel
<ra*******@gmail.com> wrote:
But why use a different one for 0 than for EXIT_SUCCESS?


because the OS expects it?

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mar 28 '06 #38
On Mon, 27 Mar 2006 23:39:54 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:
Eric Sosman <Er*********@sun.com> writes:
Keith Thompson wrote On 03/27/06 18:13,:
Eric Sosman <Er*********@sun.com> writes:
[...]

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
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mar 28 '06 #39
On 2006-03-28, Mark McIntyre <ma**********@spamcop.net> wrote:
On 27 Mar 2006 23:04:52 GMT, in comp.lang.c , Jordan Abel
<ra*******@gmail.com> wrote:
But why use a different one for 0 than for EXIT_SUCCESS?


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
Mar 28 '06 #40
On 28 Mar 2006 19:26:35 GMT, in comp.lang.c , Jordan Abel
<ra*******@gmail.com> wrote:
On 2006-03-28, Mark McIntyre <ma**********@spamcop.net> wrote:
On 27 Mar 2006 23:04:52 GMT, in comp.lang.c , Jordan Abel
<ra*******@gmail.com> wrote:
But why use a different one for 0 than for EXIT_SUCCESS?


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


Sure. Whats your point?
The rtl is quite entitled to convert 0 and EXIT_SUCCESS into whatever
it actually likes, but it needn't.
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mar 28 '06 #41


Jordan Abel wrote On 03/28/06 14:26,:
On 2006-03-28, Mark McIntyre <ma**********@spamcop.net> wrote:
On 27 Mar 2006 23:04:52 GMT, in comp.lang.c , Jordan Abel
<ra*******@gmail.com> wrote:

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


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


A programmer familiar with VMS is as familiar with
the notion of different kinds of success as others are
with different kinds of failure. Such notions arise in
everyday life, too: Did your favorite college basketball
time "win" its tournament game, or did it "win in a walk"
or "win in triple overtime?" Yes, all the variations can
be expressed as "win" (VMS condition codes encode a similar
simplification in the low-order bit), but the fact that
the sportscasters communicate the distinction suggests
that someone's believed to be interested in it.

An old joke that needs to be read aloud with a Beebish
intonation: "And now for the results of today's football
matches. Arsenal one, Birmingham lost, ..."

--
Er*********@sun.com

Mar 28 '06 #42
On 2006-03-28, Eric Sosman <Er*********@sun.com> wrote:


Jordan Abel wrote On 03/28/06 14:26,:
On 2006-03-28, Mark McIntyre <ma**********@spamcop.net> wrote:
On 27 Mar 2006 23:04:52 GMT, in comp.lang.c , Jordan Abel
<ra*******@gmail.com> wrote:
But why use a different one for 0 than for EXIT_SUCCESS?

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


A programmer familiar with VMS is as familiar with
the notion of different kinds of success as others are
with different kinds of failure. Such notions arise in
everyday life, too: Did your favorite college basketball
time "win" its tournament game, or did it "win in a walk"
or "win in triple overtime?" Yes, all the variations can
be expressed as "win" (VMS condition codes encode a similar
simplification in the low-order bit), but the fact that
the sportscasters communicate the distinction suggests
that someone's believed to be interested in it.


And they'll probably want to use their implementation-defined specific
exit codes instead of picking between 0 and EXIT_SUCCESS. There's no
reason for 0 not to be a synonym for EXIT_SUCCESS, since they're both
equally generic "win"s.
Mar 28 '06 #43
Mark McIntyre <ma**********@spamcop.net> writes:
On 28 Mar 2006 19:26:35 GMT, in comp.lang.c , Jordan Abel
<ra*******@gmail.com> wrote:
On 2006-03-28, Mark McIntyre <ma**********@spamcop.net> wrote:
On 27 Mar 2006 23:04:52 GMT, in comp.lang.c , Jordan Abel
<ra*******@gmail.com> wrote:

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

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


Sure. Whats your point?
The rtl is quite entitled to convert 0 and EXIT_SUCCESS into whatever
it actually likes, but it needn't.


The point, I think, is that "because the OS expects it" is not a
reason to have a value other than 0 for EXIT_SUCCESS. Since 0 is
required to indicate success, defining EXIT_SUCCESS as 0 works just
fine. As far as I know, all implementations define EXIT_SUCCESS as
0 -- even VMS.

If the standard had required EXIT_SUCCESS to be defined as 0, it would
have made no real difference.

It's true that an implementation *may* define EXIT_SUCCESS as
something other than 0, but there's really no reason to do so.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Mar 28 '06 #44
Eric Sosman wrote:
.... snip ...
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.


Not so, especially in the embedded world. There none of the
standard library may be used, and the only really interesting
header is stddef.h.

--
"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/>
Mar 28 '06 #45


CBFalconer wrote On 03/28/06 16:22,:
Eric Sosman wrote:

... snip ...
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.

Not so, especially in the embedded world. There none of the
standard library may be used, and the only really interesting
header is stddef.h.


I should, perhaps, have written "almost every
hosted program." Only "perhaps," though, because the
context you snipped was about using <stdlib.h> to get
the definitions of EXIT_SUCCESS and EXIT_FAILURE.
I'm given to understand that these macros are rather
sparsely used in freestanding code ...

--
Er*********@sun.com

Mar 28 '06 #46
Eric Sosman <Er*********@sun.com> writes:
CBFalconer wrote On 03/28/06 16:22,:
Eric Sosman wrote:

... snip ...
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.

Not so, especially in the embedded world. There none of the
standard library may be used, and the only really interesting
header is stddef.h.


I should, perhaps, have written "almost every
hosted program." Only "perhaps," though, because the
context you snipped was about using <stdlib.h> to get
the definitions of EXIT_SUCCESS and EXIT_FAILURE.
I'm given to understand that these macros are rather
sparsely used in freestanding code ...


It would have been reasonable to define EXIT_SUCCESS and EXIT_FAILURE
in all the same headers that currently defined NULL (which is perhaps
the most widely used name from the stnadard headers).

(Context: This is assuming a model in which EXIT_SUCCESS and
EXIT_FAILURE are the only portable values to pass to exit() or to
return from main(), and exit(0), like exit(1) is non-portable. This
would have been cleaner than the model that was adopted, in which
EXIT_SUCCESS and 0 both denote success, but not necessarily in the
same way.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Mar 28 '06 #47
On Mon, 27 Mar 2006 21:21:50 -0500, Joe Wright wrote:
Eric Sosman wrote:
Keith Thompson wrote:
Eric Sosman <Er*********@sun.com> writes:

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

> Eric Sosman <Er*********@sun.com> writes: [...]
>
>
>> 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?


I am neither Eric nor Keith but I can't resist a thread where there is
some merit in having bean around for a while. I first wrote "hello
world\n" (and I think it was indeed that) in 1978/9. I got the job in '78
but I did not get to use the cool CS types PDP 11 right away so I am not
sure exactly. It was just *before* they got all excited about the Unix
release whose C compiler had long ints and allowed structure assignments
(and function return values).

I played a bit and then got back to the serious stuff with FORTRAN on and
IBM 360 and B (yes B!) on a Honeywell something-or-other.

--
Ben.
Mar 29 '06 #48
Jordan Abel <ra*******@gmail.com> wrote:
On 2006-03-27, Mark McIntyre <ma**********@spamcop.net> wrote:
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?


Because on OSes where the difference can be significant, it is nice to
be able to return both "program terminated successfully by default" and
"program terminated successfully by explicit decision of the
programmer"?

Richard
Mar 29 '06 #49
On Tue, 28 Mar 2006 20:34:33 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:
It's true that an implementation *may* define EXIT_SUCCESS as
something other than 0, but there's really no reason to do so.


Sure. On the other hand, there's no reason for EXIT_SUCCESS to be
defined as zero either, since it isn't obligated to be zero.

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mar 29 '06 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: sivignon | last post by:
Hi, I'm writing a php script which deals with 3 ORACLE databases. This script is launch by a script shell on an linux machine like this : /../php/bin/php ./MySript.php (PHP 4.3.3) My script...
3
by: diyanat | last post by:
i am writing a cgi script in C using the CGIC library, the script fails to run, i am using apache on linux error report from apache : internal server error Premature end of script headers:...
16
by: laberth | last post by:
I've got a segmentation fault on a calloc and I don'tunderstand why? Here is what I use : typedef struct noeud { int val; struct noeud *fgauche; struct noeud *fdroit; } *arbre; //for those...
3
by: Zheng Da | last post by:
Program received signal SIGSEGV, Segmentation fault. 0x40093343 in _int_malloc () from /lib/tls/libc.so.6 (gdb) bt #0 0x40093343 in _int_malloc () from /lib/tls/libc.so.6 #1 0x40094c54 in malloc...
5
by: Fra-it | last post by:
Hi everybody, I'm trying to make the following code running properly, but I can't get rid of the "SEGMENTATION FAULT" error message when executing. Reading some messages posted earlier, I...
18
by: Digital Puer | last post by:
Hi, I'm coming over from Java to C++, so please bear with me. In C++, is there a way for me to use exceptions to catch segmentation faults (e.g. when I access a location off the end of an array)?...
27
by: Paminu | last post by:
I have a wierd problem. In my main function I print "test" as the first thing. But if I run the call to node_alloc AFTER the printf call I get a segmentation fault and test is not printed! ...
7
by: pycraze | last post by:
I would like to ask a question. How do one handle the exception due to Segmentation fault due to Python ? Our bit operations and arithmetic manipulations are written in C and to some of our...
3
by: madunix | last post by:
My Server is suffering bad lag (High Utlization) I am running on that server Oracle10g with apache_1.3.35/ php-4.4.2 Web visitors retrieve data from the web by php calls through oci cobnnection...
6
by: DanielJohnson | last post by:
int main() { printf("\n Hello World"); main; return 0; } This program terminate just after one loop while the second program goes on infinitely untill segmentation fault (core dumped) on...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: Aftab Ahmad | last post by:
Hello Experts! I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.