time(0L) - history of a misconception (was Re: SCO password generator)

David Fiander david at sco.COM
Wed May 22 23:07:13 AEST 1991


In article <381 at tmcsys.UUCP> lh at aega84.UUCP (L. Hirschbiegel) writes:
>
>You're a cousin of "lint", aren't you :-) ?
>

No, he's somebody that knows the difference between a null pointer and
the integer zero.

>Ever tried to RTFM for yourself? 
>
>	  NAME
>	       time - get time
>
>	  DESCRIPTION
>	       The time	system call returns the	value of time in seconds
>	       since 00:00:00 Greenwich	Mean Time (GMT), January 1, 1970.

You missed a line which appears in _my_ FM:

	long *tloc;


>If you still don't understand: I'll help you! 
>For this little test program:
>
>main()
>{
>time(0L);
>time((long *)0);
>}
>
>the assembler output from my C compiler is:
>
> [assembler code deleted,  I try to avoid it]
>

So you're using GCC on an intel platform (i386 obviously, it wouldn't fit
on anything else).

Lucky you, you've never had to program an Cyber 180.  If you tried that
trick on any CDC machine , you would get a "Ring-0" hardware exception
and, if you hadn't installed a handler, your program could get blown off
(I think.  I never used NOS/VE, and what I used just caused a disgusting
penalty hit, since we trapped to the OS, it said "shithead programmer,"
and returned).

There exist architectures on which the NULL pointer is different from
"all bits 0".  In fact, if you can get the compiler people to agree to
it, the best value for the NULL pointer is something that is an invalid
virtual memory address, because then, when somebody tries to dereference
it, you get a core dump (note that 0 might be a valid address which would
never be referred to by the user, for example: the address of the C
startup code).  The large part of a project I was involved was spent
inserting necessary casts into function calls, in order to _fix_ code
written by people that believed 

>
>Repeat after me: IT DOESN'T MATTER :-)

--
David J. Fiander
SCO MMDF Development Team
SCO Canada, Inc.



More information about the Comp.unix.sysv386 mailing list