Re: cygwin1.dll bug in ftime

["Wu Yongwei" <adah at netstd dot com>]

First I'll answer your question 3. Having defined timezone does not mean it
will work.

----------------------------------------
#include <stdio.h>
#include <time.h>

int main()
{
    tzset();
    printf("%ld\n", timezone);
    printf("%ld\n", _timezone);
    return 0;
}
----------------------------------------
$ gcc -Wall test.c
test.c: In function `main':
test.c:7: warning: long int format, pointer arg (arg 2)

$ ./a
4198632
-28800
----------------------------------------

Enough? (Not well tested, uh?)

Second, no one should ignore backward compatibility (M$'s success is partly
owing to this, as well as Unix's popularity), as long as it does not violate
the design rules (standards-conformance, etc.). I don't think, say,
respecting the second argument of gettimeofday is a sin; those not wanting
it can simply pass NULL.

There is a SERIOUS misunderstanding about standards conformance here. An
unusable timezone is a violation, but well-behaved ftime and gettimeofday
are NOT.

Just as the morale of network protocol implementation is: Be generous to
accept, and be prudent to send. So I think in programming we also should
make environments (run-times, librabries) as compatible as possible, and
write applications as portable as possible.

A standard should specify what we SHOULD do, but it never restricts what we
COULD do. Not to mention that what I asked for has long been there in the
UNIX tradition already.

As I have said already, "unspecified" in a standard means the standard does
not say anything about the implementation, and, IMHO, the implementors are
free to choose from the best practices. Better practices mean better
compatibility, don't they?

Summary of my points. Making ftime and gettimeofday get timezone information
is not a violation of any standards, and will make Cygwin only better
(unless someone thinks better compatibility is a sin).

Hope I am clear enough. I am arguing here for a BETTER Cygwin.

Best regards,

Wu Yongwei

--- Original Message from Karsten Fleischer ---

> Thank you for your suggestions. The points are:
>
> 1) Cygwin did very well, but not now;

That's irrelevant, Cygwin's behavior is SUSv2 compliant, AFAICS.

> 2) I was not using ftime to get time, but to get timezone information.

OK, another quote from the SUSv3 docs
http://www.opengroup.org/onlinepubs/007904975/functions/ftime.html:

--->>
FUTURE DIRECTIONS
This function may be withdrawn in a future version.
<<---

[This wasn't in the SUSv2 docs, though.]
So, _do not_ use this function to get time or timezone information.

> 3) timezone variable is not usable in Cygwin.

Why not?

In my installation 1.3.10 installation I see this in the <time.h> header
file:

--->>
#ifndef timezone
#define timezone ((long int) _timezone)
#endif
<<---

And _timezone is declared some lines above:

--->>
extern __IMPORT time_t _timezone;
<<---

This is not strictly following the SUSv2 or SUSv3 standards, but it
should work.
SUSv2 says:

--->>
The following are declared as variables:


extern int       daylight;
extern long int  timezone;
extern char     *tzname[];
<<---

SUSv3 says:

--->>
The following shall be declared as variables:

extern int    daylight;
extern long   timezone;

extern char  *tzname[];
<<---

timezone is a macro on Cygwin, but the typecast is OK.
You can dig through the Cygwin sources and send in a patch to make
Cygwin fully SUS compliant.


> So timezone is now not portable. Cygwin broke some "unportable" code.

It didn't talk about "unportable" code.
What I was trying to say is, that you wrote code that doesn't follow the
standards and that is likely to break on any other platform.
Read the SUSv2 at the link that Christopher Faylor gave you already.
SUSv3 is quite new, so it's likely that other platforms are not really
compliant to this new standard, yet.

Karsten


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/