Newbie question on time()

M

Mike Wahler

Floyd Davidson said:
Your point is well taken because the two are both equally
acceptable per the Standard, which says,

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

To me that indicates (as far a C is concerned) there are only
two possible values of status that can be returned, _successful_
and _unsuccessful_. And either a "zero or EXIT_SUCCESS" result
in a unique, singular _successful_ status, making them
necessarily equal.

However, Ben Pfaff is certainly teasing us with something
specific in mind, and I would like to hear him expand on it
because obviously there is more to this than I'm seeing.

I don't think he's 'teasing', but clarifying. When
returned from the main() function, both 'EXIT_SUCCESS'
and zero have the same meaning: "successful program
completion." This does not necessarily indicate that
the value of 'EXIT_SUCCESS' is zero. Think of those
two values as 'synonyms' with respect to *meaning*, in
the context of main()'s return value.

-Mike
 
B

Ben Pfaff

Floyd Davidson said:
Default User said:
However, it was not a reasonable correction of the posted code.
[...]
However, Ben Pfaff is certainly teasing us with something
specific in mind, and I would like to hear him expand on it
because obviously there is more to this than I'm seeing.

Some people in the past in this newsgroup have presumed that
EXIT_SUCCESS must expand to (a constant expression with value) 0.
This is not the case. It could have the value 1, 6, 23, or
whatever other value is appropriate for the implementation.
That's all I'm trying to point out.
 
F

Floyd Davidson

Mike Wahler said:
I don't think he's 'teasing', but clarifying. When
returned from the main() function, both 'EXIT_SUCCESS'
and zero have the same meaning: "successful program
completion." This does not necessarily indicate that
the value of 'EXIT_SUCCESS' is zero. Think of those
two values as 'synonyms' with respect to *meaning*, in
the context of main()'s return value.

I wouldn't agree with that interpretation at all. If the actual
value of the EXIT_SUCCESS macro is not 0, then the value of
"return 0;" will also not be 0. Just as EXIT_SUCCESS is
converted to something before the program exits, so will "return
0;" be converted to the same identical thing. (C on a VMS
platform being an example.)

What you are saying is that the two tokens, "0" and
"EXIT_SUCCESS" are not spelled the same, which is not much of a
revelation.

What they evaluate to internally, even if at different places,
is of significance. And as near as I can tell, they evaluate to
the same value, "success". Is that not correct?
 
F

Floyd Davidson

Ben Pfaff said:
Floyd Davidson said:
Default User said:
Ben Pfaff wrote:
Zygmunt Krynicki wrote:
On Fri, 03 Oct 2003 23:59:49 -0400, Al Bowers wrote:

return 0;

return EXIT_SUCCESS;

They mean the same thing.

Yes. However, they are not necessarily equal.

However, it was not a reasonable correction of the posted code.
[...]
However, Ben Pfaff is certainly teasing us with something
specific in mind, and I would like to hear him expand on it
because obviously there is more to this than I'm seeing.

Some people in the past in this newsgroup have presumed that
EXIT_SUCCESS must expand to (a constant expression with value) 0.
This is not the case. It could have the value 1, 6, 23, or
whatever other value is appropriate for the implementation.
That's all I'm trying to point out.

I've never programmed on a VMS system, so I'm not positive how
that works... ;-)

Isn't the same conversion also guaranteed for "return 0;", on
any system where "success" is not represented by the value 0?
 
R

Richard Heathfield

Floyd said:
Ben Pfaff said:
Floyd Davidson said:
Ben Pfaff wrote:
Zygmunt Krynicki wrote:
On Fri, 03 Oct 2003 23:59:49 -0400, Al Bowers wrote:

return 0;

return EXIT_SUCCESS;

They mean the same thing.

Yes. However, they are not necessarily equal.

However, it was not a reasonable correction of the posted code. [...]
However, Ben Pfaff is certainly teasing us with something
specific in mind, and I would like to hear him expand on it
because obviously there is more to this than I'm seeing.

Some people in the past in this newsgroup have presumed that
EXIT_SUCCESS must expand to (a constant expression with value) 0.
This is not the case. It could have the value 1, 6, 23, or
whatever other value is appropriate for the implementation.
That's all I'm trying to point out.

I've never programmed on a VMS system, so I'm not positive how
that works... ;-)

Isn't the same conversion also guaranteed for "return 0;", on
any system where "success" is not represented by the value 0?

No. A /similar/ conversion is guaranteed, but it may not be the same one. On
a system where two or more different results all mean "success" to the
calling environment, there is no requirement in the Standard that 0 and
EXIT_SUCCESS map to the same result. Thus, it may be possible in some
environments to distinguish between different flavours of success.
 
M

Mike Wahler

Floyd Davidson said:
I wouldn't agree with that interpretation at all.

You are of course entitled to your opinion.
If the actual
value of the EXIT_SUCCESS macro is not 0, then the value of
"return 0;" will also not be 0.

It might be, it might not.
Just as EXIT_SUCCESS is
converted to something

might or might not be converted to a value other than
that specified by the EXIT_SUCCESS macro
before the program exits, so will "return
0;" be converted to the same identical thing.

Not necessarily.
(C on a VMS
platform being an example.)

That might be the behavior of a given impelementation
for that platform.

The behavior could easily be different for other
implementations/platforms. That's the whole point:
it's an abstraction, not tied to a particular platform.
It's the implementation's responsibility to translate
to whatever the host platform uses to mean "success".
Nothing (from the language perspective) rules out that
there be more than one value which indicates success.
What you are saying is that the two tokens, "0" and
"EXIT_SUCCESS" are not spelled the same, which is not much of a
revelation.

No I'm not simply stating the obvious. I'm stating that
the *meaning* of zero and EXIT_SUCCESS is the same when
used as the return value of main().

What they evaluate to internally, even if at different places,
is of significance.

Not to the language. They mean simply "successful completion".
Period.
And as near as I can tell, they evaluate to
the same value, "success".

"success" is not a value, it's a "condition". They have the
same *meaning*.

Is that not correct?

IMO no.

-Mike
 
M

Mike Wahler

Floyd Davidson said:
Ben Pfaff said:
Floyd Davidson said:
Ben Pfaff wrote:
Zygmunt Krynicki wrote:
On Fri, 03 Oct 2003 23:59:49 -0400, Al Bowers wrote:

return 0;

return EXIT_SUCCESS;

They mean the same thing.

Yes. However, they are not necessarily equal.

However, it was not a reasonable correction of the posted code. [...]
However, Ben Pfaff is certainly teasing us with something
specific in mind, and I would like to hear him expand on it
because obviously there is more to this than I'm seeing.

Some people in the past in this newsgroup have presumed that
EXIT_SUCCESS must expand to (a constant expression with value) 0.
This is not the case. It could have the value 1, 6, 23, or
whatever other value is appropriate for the implementation.
That's all I'm trying to point out.

I've never programmed on a VMS system, so I'm not positive how
that works... ;-)

So why did you give VMS as an example in your other post?

Isn't the same conversion also guaranteed for "return 0;", on
any system where "success" is not represented by the value 0?

Yes. And this contradicts what you said in your other post.

-Mike
 
F

Floyd Davidson

Mike Wahler said:
Floyd Davidson said:
Ben Pfaff said:
Ben Pfaff wrote:
Zygmunt Krynicki wrote:
On Fri, 03 Oct 2003 23:59:49 -0400, Al Bowers wrote:

return 0;

return EXIT_SUCCESS;

They mean the same thing.

Yes. However, they are not necessarily equal.

However, it was not a reasonable correction of the posted code.
[...]
However, Ben Pfaff is certainly teasing us with something
specific in mind, and I would like to hear him expand on it
because obviously there is more to this than I'm seeing.

Some people in the past in this newsgroup have presumed that
EXIT_SUCCESS must expand to (a constant expression with value) 0.
This is not the case. It could have the value 1, 6, 23, or
whatever other value is appropriate for the implementation.
That's all I'm trying to point out.

I've never programmed on a VMS system, so I'm not positive how
that works... ;-)

So why did you give VMS as an example in your other post?

I understand that is one example where, at least prior to ANSI
C, an exit status of 0 was not success. Perhaps my memory is
wrong?
Yes. And this contradicts what you said in your other post.

I see no contradiction with what I said, so perhaps you
misunderstood it or I didn't make it clear.

Your argument in that article came down to my use of the word
"value" which you say should have been "condition". That's just
semantics, and I think you've read more into the term "value"
than I intended. I did not mean a "numerical value", I meant a
boolean value which toggles between /successful/ /termination/
and /unsuccessful/ /termination/.

The only variation from what I described is the one Richard
Heathfield points out, where there might be multiple types of
"success". However, the C Standard doesn't support that, except
as implementation-defined, any more than it supports multiple
types of "failure" which are also implementation-defined.

§7.20.4.3
...

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

"[t]he /status /successful/ /termination/" is singular, and
indicates both EXIT_SUCCESS and zero will be converted to the
same thing.

I agree with Ben Pfaff that EXIT_SUCCESS is not necessarily 0,
but whatever it is must be handled the same as if it were 0.
There seems to be no absolute necessity to ever define it as
other than 0 simply because, since EXIT_SUCCESS is a macro, its
conversion will be handled by the pre-processor, while 0 will be
handled later. That still doesn't mean it can't be other than
0 though.
 
R

Richard Heathfield

Floyd Davidson wrote:

I agree with Ben Pfaff that EXIT_SUCCESS is not necessarily 0,
but whatever it is must be handled the same as if it were 0.

Well, they both map to "successful termination" (although, as I said before,
there is no necessity for them both to map to the /same/ "successful
termination"). If 0 isn't a success code on the host environment, then the
compiler has to do some behind-the-scenes magic to ensure that the
appropriate mapping is performed. Same goes for the value of EXIT_SUCCESS,
whatever that may be. (I think I'm preaching to the choir here, though.)
There seems to be no absolute necessity to ever define it as
other than 0 simply because, since EXIT_SUCCESS is a macro, its
conversion will be handled by the pre-processor, while 0 will be
handled later.

Well, the pre-processor might handle it "a bit", and then rely on the
compiler to do the rest. For example, I believe the implementation would be
justified in doing this:

#define EXIT_SUCCESS __success

or even this:

#define EXIT_SUCCESS __success()
That still doesn't mean it can't be other than
0 though.

Right.
 
F

Floyd Davidson

Richard Heathfield said:
Well, the pre-processor might handle it "a bit", and then rely on the
compiler to do the rest. For example, I believe the implementation would be
justified in doing this:

#define EXIT_SUCCESS __success

or even this:

#define EXIT_SUCCESS __success()

I was thinking in terms of

#define EXIT_SUCCESS 0

where exit(3) is defined as something like

void exit(int status)
{
extern int __status;
if (status == 0) {
__status = __exit_success(status);
} else {
__status = __exit_failure(status);
}
...
}

Whatever is done with exit(0), is done with exit(EXIT_SUCCESS).
Of course, that doesn't necessarily rule out the multiple forms
of /successful/ /termination/ in the same manner that you are
hinting at with __success().

Your example with __success is reasonable and provides two
possible forms for /successful/ /termination/.

But why pass a value from __success(), which a programmer could
also code manually by accident while probably expecting a
failure code, through the exit() function? If there are
multiple forms, exit() has to separate the different values
passed as an argument anyway, and while exit() could simply do
something different for __success and 0, __success() depends on
the system having magic knowledge of program exit status, which
can just as well be produced inside exit(), with what I've
labeled as __exit_success(), and thus be protected from being
stepped on by the programmer.
 
P

Peter Nilsson

Floyd Davidson said:
Your point is well taken because the two are both equally
acceptable per the Standard, which says,

The following context is important...

7.20.4.3 The exit function
Synopsis
5 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.

*Here*, the term 'status' refers to the parameter.

In 5.1 (Conceptual models) the term 'terminating status' is not defined as
being an integer or other object. It is simply *a* 'status' returned to the
host. It's form is not specified by the standard.

The termination status is deduced from the exit parameter, or main return
value, or absense thereof. But there may be more than one way for the
implementation to signal to the host that there is a successful (or
unsuccessful) termination.
To me that indicates (as far a C is concerned) there are only
two possible values of status that can be returned, _successful_
^^^^^^^^^^^^^^^^
and _unsuccessful_.

Like I said, the form of the status returned by the implementation to the
host is not specified. The term 'values' need not be applicable. You're
better off replacing the underlined phrase with the word 'classes'.

[Note that some hosts ignore the status, whatever the class.]
 
F

Floyd Davidson

Peter Nilsson said:
The following context is important...

Context is everything.
7.20.4.3 The exit function
Synopsis


*Here*, the term 'status' refers to the parameter.

It refers to what happens after control is returned to the host
environment, and the parameter 'status' no longer exists. Or,
at least for the "form of the status successful termination" and
in the last sentence, "the status returned is ..."

The places where it means the parameter are all "value of
status".
In 5.1 (Conceptual models) the term 'terminating status' is not defined as
being an integer or other object. It is simply *a* 'status' returned to the
host. It's form is not specified by the standard.

And that is what the term 'status' above, except as noted,
means.
The termination status is deduced from the exit parameter, or main return
value, or absense thereof. But there may be more than one way for the
implementation to signal to the host that there is a successful (or
unsuccessful) termination.

That is a point which Richard Heathfield has previously brought
up. I'm not sure I agree that the wording allows that, but if
it does the exit parameter (whether 0 or EXIT_SUCCESS) merely
says it is a successful termination, and the system uses
whatever magic it has available to determine which form of
successful termination it is.

Granted, that would have been better states as "forms of status",
rather than overloading the word values, but the immediate reference
to successful and unsuccessful makes it clear that it does not
refer to the numerical value of the parameter.
Like I said, the form of the status returned by the implementation to the
host is not specified. The term 'values' need not be applicable. You're
better off replacing the underlined phrase with the word 'classes'.

I believe you are digging too deep to find fault with the English,
rather than with the meaning. 'Classes' is no more useful that
'values'. The Standard uses the term 'form', and we probably should
too, eh?
[Note that some hosts ignore the status, whatever the class.]
 
R

Richard Heathfield

Floyd Davidson wrote:

Your example with __success is reasonable and provides two
possible forms for /successful/ /termination/.

But why pass a value from __success(), which a programmer could
also code manually by accident while probably expecting a
failure code, through the exit() function?

Why indeed? :) I'm just trying to clarify what I believe is legal for an
implementation, not what I necessarily think is a good idea!
 
K

Keith Thompson

Mike Wahler said:
As the return value from 'main()', both of those
values have the same meaning.

Maybe. The wording in the standard (C99 7.20.4.3 p5) (using
underscores to denote italics) is:

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.

(This is in the description of the exit() function; a return from main
is essentially equivalent for our purposes.)

It's not clear whether "return 0;" and "return EXIT_SUCCESS;" return
the *same* status. It's possible for an implementation to have
multiple status values that indicate success. I *think* that the
wording of the standard implies that they have to return the same
implementation-defined status, but one could argue either way.

I suspect that they're equivalent for all real implementations, and I
can't think of any good reason for them to be distinct.
 
K

Keith Thompson

Mike Wahler said:
If that is the standard library's 'time()' function,
then that is invalid statement.

Agreed. On the other hand, it's plausible that a call to time() with
no arguments could result in the same generated code as a valid
time(NULL) call. Doing exactly what you expect is, after all, one of
the (infinitely many) possible consequences of undefined behavior.
 
G

Gordon Burditt

return EXIT_SUCCESS;
Maybe. The wording in the standard (C99 7.20.4.3 p5) (using
underscores to denote italics) is:

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.

(This is in the description of the exit() function; a return from main
is essentially equivalent for our purposes.)

It's not clear whether "return 0;" and "return EXIT_SUCCESS;" return
the *same* status. It's possible for an implementation to have
multiple status values that indicate success. I *think* that the
wording of the standard implies that they have to return the same
implementation-defined status, but one could argue either way.

I see nothing in the wording above that prevents an implementation
from having exit statuses include EXIT_SUCCESS_WITH_PROMOTION_AND_RAISE
(equal to EXIT_SUCCESS) and
EXIT_SUCCESS_AND_YOU_KEEP_YOUR_JOB_FOR_ANOTHER_WEEK (equal to zero).
(no, I didn't say these were defined in <stdlib.h>). It doesn't
say the two implementation-defined forms have to be the same.

I suspect that they're equivalent for all real implementations, and I
can't think of any good reason for them to be distinct.

I can think of good reason for having multiple successful
(implementation-defined) exit statuses. For example, a file compare
program usually has at least 3 possible results: files compare
equal, files compare not equal, and trouble (files cannot be opened,
i/o errors, program manually interrupted, etc.). Some people think
the common mapping of "files compare not equal" to a failure status
is a bit wierd, as the compare was successful, it just came up with
an answer someone might not like.

Gordon L. Burditt
 
F

Floyd Davidson

I see nothing in the wording above that prevents an implementation
from having exit statuses include EXIT_SUCCESS_WITH_PROMOTION_AND_RAISE
(equal to EXIT_SUCCESS) and
EXIT_SUCCESS_AND_YOU_KEEP_YOUR_JOB_FOR_ANOTHER_WEEK (equal to zero).
(no, I didn't say these were defined in <stdlib.h>). It doesn't
say the two implementation-defined forms have to be the same.

The Standard does not say "implementation *forms*" (emphasis
added). It says "an implementation-defined form of the status
_successful termination_ is returned."

It only references one single form, not two or ten.
 
M

Micah Cowan

I see nothing in the wording above that prevents an implementation
from having exit statuses include EXIT_SUCCESS_WITH_PROMOTION_AND_RAISE
(equal to EXIT_SUCCESS) and
EXIT_SUCCESS_AND_YOU_KEEP_YOUR_JOB_FOR_ANOTHER_WEEK (equal to zero).
(no, I didn't say these were defined in <stdlib.h>). It doesn't
say the two implementation-defined forms have to be the same.

No, but I agree with Mr. Thompson (whose attribution you seem to
have mislaid someplace) that it appears toe be implied, through
the use of the definite article:

...an implementation-defined from of the status...
^^^

But I'm not sure if this is strong enough.
I can think of good reason for having multiple successful
(implementation-defined) exit statuses. For example, a file compare
program usually has at least 3 possible results: files compare
equal, files compare not equal, and trouble (files cannot be opened,
i/o errors, program manually interrupted, etc.). Some people think
the common mapping of "files compare not equal" to a failure status
is a bit wierd, as the compare was successful, it just came up with
an answer someone might not like.

Any reason for multiple successful exit statuses would be
implementation-defined, since the C standard certainly doesn't
address them, so you wouldn't be able to count on them in
portable code. I think it'd be damn ugly for an implementation to
treat 0 and EXIT_SUCCESS differently. But, assuming my somewhat
thin argument about the implications of the standard's use of the
definite article isn't good enough, it's a QoI issue.

-Micah
 
D

Dan Pop

In said:
srand(time())

The 'time()' function has one parameter, for which
an argument must be supplied by the caller. The call
you show above should not compile.
^^^^^^^^^^^^^^^^^^
That's a bold statement for code invoking undefined behaviour:

fangorn:~/tmp 427> cat test.c
#include <stdlib.h>

int main()
{
srand(time());
return 0;
}
fangorn:~/tmp 428> gcc -ansi -pedantic test.c
fangorn:~/tmp 429>

So, let's rephrase: "if the code includes <time.h>, the call you show
above should not compile without a diagnostic".
^^^^^^^^^^^^^^^^^^^^
If the author was sloppy enough to call srand(time()), it is a safe bet
that he was sloppy enough not to include <time.h>.

Dan
 
G

Gordon Burditt

It's not clear whether "return 0;" and "return EXIT_SUCCESS;" return
The Standard does not say "implementation *forms*" (emphasis
added). It says "an implementation-defined form of the status
_successful termination_ is returned."

The implementation is only returning *ONE* form. It cannot return
more than one status at any given time. I maintain it could have
a choice of several subtypes of successful termination status, but
it has to pick ONE and return ONE for any given execution.

Certainly there are implementations which can return one of several
implementation-defined forms of failure status. (Anything using
the POSIX exit() call, for example). The program need not even
be coded to return some of these forms: termination of the program
by external means (e.g. control-C or a "kill" command) may return
its own failure status independent of the code in the program,
and it might even be returned without giving the code in the program
any chance to run.
It only references one single form, not two or ten.

Gordon L. Burditt
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top