>
> On 30 Mar 2000 [EMAIL PROTECTED] wrote:
>
> > X-Authentication-Warning: roadrunner.sig.net: majordom set sender to
>[EMAIL PROTECTED] using -f
> > From: "T.E.Dickey" <[EMAIL PROTECTED]>
> > Message-Id: <[EMAIL PROTECTED]>
> > Subject: Re: lynx-dev Fixes for VMS Multinet TCPIP support + misc
> >
> [...]
> > It looked benign - so I'll probably put it in. If you have a log of the
> > build after that change, I'm curious to pick through the compiler warnings.
> >
> Not even the change looks begign but also agreed to be the best
> by the process.com team. Thanks !
It looks benign because:
+ it doesn't interact with any other headers than Multinet's
+ it's simple to disable if Multinet's definitions intrude too much.
>
> I think you did not read my posting carefully enough : let me
> cut-n-paste the relevant part again -->
yes - I read it, but didn't quote it exactly. The issue is that on most
32-bit hosts, time_t is a (signed) long value based on 1 Jan 1970.
Some vendors have changed this to an unsigned value to buy more time
on the 32-bit clock. But (except for programs that run properly on 64-bit
hosts ;-), there's a lot of equating time_t to long which is hard to flush
out using normal compiler warnings.
> Now that it should be clear to all of us that an unsigned long cannot
> be < 0, the real question now is :
>
> - Is this because some OS have time_t <> 'unsigned' ?
> YES => VMS compiler option to suppress this warning
> NO => patch the code
> 1) i.e. replace <= 0 by == 0
> 'return (unsigned long) clock2;' in this function (line 6108
> in src/LYutils.c)
> 2) recast LYmktime
something like that. I probably won't try to fix it today (we're at the
phase where that sort of bug probably will wait for the next development
cycle).
--
Thomas E. Dickey
[EMAIL PROTECTED]
http://www.clark.net/pub/dickey
