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 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.
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.
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
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!
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!
"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.
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>
"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.
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.
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
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
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?
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.
"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 ***
"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.
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.
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
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.
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
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
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?
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.
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
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.
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
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 ---
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
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.
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.
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 :)
"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.
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
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/>
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/>
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
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
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
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
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
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
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
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.
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.
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/>
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
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.
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.
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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
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:...
|
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...
|
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...
|
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...
|
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)?...
|
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!
...
|
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...
|
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...
|
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...
|
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...
|
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"....
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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)...
| |