RFC: linux compatibility

[DJ Delorie]

> > 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@sourceware.cygnus.com