473,387 Members | 1,304 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,387 software developers and data experts.

srand(time(0))

It appears that the only parameter that can be passed to time() is 0.
No other number
works (because converting from int to time_t*). If that's true, why
does it even accept
a parameter? I've googled extensively to find a reason why, but
surprisingly, there's
nothing that explains it. The only thing that alludes to a clue is
some people are passing
NULL to the function instead.

Any ideas about this?

Oct 26 '08 #1
8 8608
bill wrote:
It appears that the only parameter that can be passed to time() is 0.
No other number
works (because converting from int to time_t*). If that's true, why
does it even accept
a parameter? I've googled extensively to find a reason why, but
surprisingly, there's
nothing that explains it. The only thing that alludes to a clue is some
people are passing
NULL to the function instead.

Any ideas about this?
Any ideas about what? The specification is quite clear. 'time' accepts
a single argument that is a pointer to a 'time_t' object. If the
pointer is not null, the function assigns the value it returns to the
pointed object. IOW, instead of using the return value, you could do this:

#include <time.h>

int main()
{
time_t t;
time(&t);
}

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Oct 26 '08 #2
bill <bi*******@zippycode.netkirjutas:
It appears that the only parameter that can be passed to time() is 0.
No other number
works (because converting from int to time_t*). If that's true, why
does it even accept
a parameter?
To allow for time_t* parameters, of course. Though I'm still puzzled why
this function has two return paths. Probably some awful premature
optimization attempt from times where a pointer was 16 or 32 bit and time_t
(potentially?) 64 bit. However, this question belongs more to a C group.

Paavo
Oct 26 '08 #3
On 2008-10-26 14:12:45 -0400, Paavo Helde <no****@ebi.eesaid:
bill <bi*******@zippycode.netkirjutas:
>It appears that the only parameter that can be passed to time() is 0.
No other number
works (because converting from int to time_t*). If that's true, why
does it even accept
a parameter?

To allow for time_t* parameters, of course. Though I'm still puzzled why
this function has two return paths. Probably some awful premature
optimization attempt from times where a pointer was 16 or 32 bit and time_t
(potentially?) 64 bit. However, this question belongs more to a C group.
Appreciate the response.

But I'm curious why you think it belongs in a C group. I'm programing
in C++. The question
arises from a function I'm using in C++ and as far as I know, the
behavior may be different in
C, which is not what I use.

If this was about C style strings or something *specific* to C, I could
see your point.

Oct 27 '08 #4
bill wrote:
On 2008-10-26 14:12:45 -0400, Paavo Helde <no****@ebi.eesaid:
>bill <bi*******@zippycode.netkirjutas:
>>It appears that the only parameter that can be passed to time() is 0.
>>[redacted]
But I'm curious why you think it belongs in a C group. I'm programing
in C++. The question
arises from a function I'm using in C++ and as far as I know, the
behavior may be different in
C, which is not what I use.
No, the behavior is identical. The time() function is part of the C90
standard library, which is incorporated by reference into C++98/C++03.

Technically, it's on topic in either group, but it's fully defined in
the C90 standard.
Oct 27 '08 #5
bill <bi*******@zippycode.netkirjutas:
On 2008-10-26 14:12:45 -0400, Paavo Helde <no****@ebi.eesaid:
>bill <bi*******@zippycode.netkirjutas:
>>It appears that the only parameter that can be passed to time() is
0. No other number
works (because converting from int to time_t*). If that's true, why
does it even accept
a parameter?

To allow for time_t* parameters, of course. Though I'm still puzzled
why this function has two return paths. Probably some awful premature
optimization attempt from times where a pointer was 16 or 32 bit and
time_t (potentially?) 64 bit. However, this question belongs more to
a C group.

Appreciate the response.

But I'm curious why you think it belongs in a C group. I'm
programing in C++. The question
arises from a function I'm using in C++ and as far as I know, the
behavior may be different in
C, which is not what I use.
This function is directly inherited from C. In C++, if there was by some
reason a wish to return a result in two different ways, one could easily
have written two different functions:

time_t time();
void time(time_t* arg);

As in C there is no function overloading, this cannot be accomplished so
simply and thus (IMO) the arg=NULL hack was introduced. So the strange
syntax is caused by the C language limitations (I guess) and the
discussion about why it is needed is therefore more relevant in a group
directly discussing the C language. Technically it's on topic also here,
but it needs a C (history) expert to answer.

Paavo
Oct 27 '08 #6
On Oct 26, 2:33 am, bill <bill21...@zippycode.netwrote:
It appears that the only parameter that can be passed to
time() is 0.
Nonsense. You can pass any legal address of a time_t to it.
No other number works (because converting from int to
time_t*).
No number works, because the parameter doesn't have a numeric
type, but a pointer type. You can only pass it a pointer.
If that's true, why does it even accept a parameter?
Because that's where it puts the results.

Historically, I think that time() was defined before you could
return a long. (The very earliest C only allowed returning int,
double and pointers.) And time_t was a typedef for a long.
(The machine was a 16 bit PDP-11. And 16 bits is a bit limited
for the time in seconds, regardless of the epoch you choose.)
So the logical signature was "void time_t( long* )". (Of
course, there were no signatures at the time. And there was no
void, either; the compiler considered it to be a function
returning int, but the int value was indeterminate.)

Once you could return long, the function was modified to return
the results. But to avoid breaking existing code, it continued
to take a pointer to the results; if the pointer is not null, it
will store the results there as well.

Note that this historical reason also explains why functions
taking a time_t also have a time_t const* parameter, rather than
just a time_t. I don't think you could pass a long as an
argument either.

(I know you couldn't pass or return struct's until much later.
And on a 16 bit machine, a long is really implemented as a
struct.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oct 28 '08 #7
bill wrote:
It appears that the only parameter that can be passed to time() is 0.
No other number works
I think you have a confusion. The 0 is not an integer value, it's the
null pointer. time() takes a pointer as parameter, not an integer.

Of course you can't give an integer to it as parameter because it
doesn't take integers.
Oct 28 '08 #8
On Oct 28, 10:59 am, James Kanze <james.ka...@gmail.comwrote:
On Oct 26, 2:33 am, bill <bill21...@zippycode.netwrote:
[...]
Historically, I think that time() was defined before you could
return a long.
FWIW, I just checked the documentation of Unix version 7 (the
oldest I could get my hands on). In the specifications for C,
there is no long, period. Which would mean that the "pointer"
would have to be to an array or a struct. On the other hand,
the specification for the function time is "long time(long*)".
So I suspect that my speculations were partially wrong; you
probably could return a long as soon as it was added to the
language, but long itself wasn't added to the language until
fairly late. Late enough not to find its way into the
specifications of C in the documentation, even though it was
used in the system API and the library.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oct 29 '08 #9

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

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.