Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Date: Mon, 16 Oct 2000 17:56:45 -0400
Message-Id: <200010162156.RAA13645@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: tiberius AT braemarinc DOT com
CC: cygwin AT sourceware DOT cygnus DOT com
In-reply-to: <001201c037ac$026e2790$1d01a8c0@BRAEMARINC.COM>
	(tiberius AT braemarinc DOT com)
Subject: Re: RFC: linux compatibility
References:  <001201c037ac$026e2790$1d01a8c0 AT BRAEMARINC DOT COM>


> > timezone in cygwin1.dll is "char *timezone();"
> >
> > timezone in linux is "extern int timezone;"
> 
> Sounds like the Cygwin way is better.  POSIX must have something to
> say on this particular issue, no?

No.  POSIX defers to ANSI.  ANSI acknowledges that timezones exist,
but offers no way to get to them.  This is strictly a BSD vs SYSV
question.

> > So what you're saying is that we can *never* migrate to the new
> > definition?
> 
> Is the global variable way the new definition?  I'm not sure we'd want to
> migrate to it.  But #defining it makes it easy to do both.

*If* we want to be linux-compatible, we need timezone to be a
variable, not a function.

> I'm assuming 'extern int timezone' is in a standard header
> somewhere.  Is this not the case?

On systems that define it that way, it's in <time.h>

> > even though plenty of existing sources
> > *assume* "extern int timezone;" without including any headers?
> 
> Then those apps are broken and should be fixed to include whatever
> header this global variable is defined in.

I agree, but I don't want it to be freshly broken because of something
we did.  Plus, there's still the problem of existing applications.
They expect the DLL to do it the old way, and I'd rather not
perpetuate that forever as part of a "migration".

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com