On Tue, Mar 26, 2002 at 11:58:00AM +0800, Wu Yongwei wrote:
>I did not submit a patch because I did not think you will accept it.
>Writing the patch itself is easy: it was already there in an old CVS
>version. Or almost so. Notice that I do not always call tzset. My
>previous experience with MS
Sorry, Christopher, but I thought I needed to answer others' questions and
clear myself. Because I need to copy and paste the content of your messages
to my reply (I don't want the garbage produced by Lotus Notes to interfere),
I can hardly write just below the original message and maybe the corre
else whole cygwin wouldn't exist!
Bye, Heribert ([EMAIL PROTECTED])
> -Original Message-
> From: Wu Yongwei [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, March 26, 2002 03:46
> To: [EMAIL PROTECTED]
> Subject: Re: cygwin1.dll bug in ftime
>
[Heribert]
March 26, 2002 14:41
> To: [EMAIL PROTECTED]
> Subject: Re: cygwin1.dll bug in ftime
>
[Heribert] [snip]
> Note that my quotation says about "the GNU operating system", and even at
> that time gettimeofday should return -1 and set errno. Cygwin does not do
On Tue, Mar 26, 2002 at 09:41:11PM +0800, Wu Yongwei wrote:
>Glibc is at least an important implementation. Don't we need compatibility?
No. Why are you asking this question again?
Didn't you actually quote the linux man page which says not to use the
second argument in gettimeofday?
"The
Glibc is at least an important implementation. Don't we need compatibility?
Note that my quotation says about "the GNU operating system", and even at
that time gettimeofday should return -1 and set errno. Cygwin does not do
it.
I wrote the patch. I argue for its legitimacy. In fact, it is scroll
From: "Wu Yongwei" <[EMAIL PROTECTED]>
>
> This is from the glibc documentation (is glibc meaningless to the Cygwin
> project?):
I'm not sure what you mean by "meaningless", but glibc is of no
particular relevance to Cygwin.
> ...
> The GNU operating system does not support using struct
>
OK, here is the patch for src/winsup/cygwin/times.cc:
--- times.cc.oldTue Mar 26 11:36:53 2002
+++ times.ccTue Mar 26 11:53:42 2002
@@ -156,4 +156,5 @@
{
static hires gtod;
+ static tzflag;
LONGLONG now = gtod.usecs (fal
When I write new code, _I_ will not use ftime again. In fact, I have fixed
my synctime program with an ugly "ifndef __CYGWIN__" macro and replaced
code using ftime with _timezone (timezone). However, breaking legacy code
is not good behaviour for a (runtime) environment.
Also, I don't intend my c
Yongwei,
At 18:45 2002-03-25, you wrote:
>...
>
>Hope I am clear enough. I am arguing here for a BETTER Cygwin.
No. You're asking to be let off the hook for either writing intrinsically
portable code or of featuring it with conditional compilation directives so
that it functions as you want it
On Tue, Mar 26, 2002 at 10:45:32AM +0800, Wu Yongwei wrote:
>Hope I am clear enough. I am arguing here for a BETTER Cygwin.
I guess I wasn't clear enough.
SUPPLY A PATCH TO FIX THE BEHAVIOR.
If you want me, or anyone else to fix it, you'll undoubtedly have a long
wait. Especially since you hav
First I'll answer your question 3. Having defined timezone does not mean it
will work.
#include
#include
int main()
{
tzset();
printf("%ld\n", timezone);
printf("%ld\n", _timezone);
return 0;
}
$
> 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/o
On Mon, Mar 25, 2002 at 04:48:49PM +0800, Wu Yongwei wrote:
>This is from the glibc documentation (is glibc meaningless to the Cygwin
>project?):
Yes.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation:
Sounds to me like Cygwin is SUS-compliant here to me. Perhaps you'd get a
more sympathetic response if you posted code that does what you need, is
itself SUS-compliant, and has trouble on Cygwin but not other SUS-compliant
platforms. While it's always preferable that bug reports come with patch
Thank you for your suggestions. The points are:
1) Cygwin did very well, but not now;
2) I was not using ftime to get time, but to get timezone information.
3) timezone variable is not usable in Cygwin.
So timezone is now not portable. Cygwin broke some "unportable" code.
Best regards,
Wu Yo
> Also notes the usage of "unspecified". "Unspecified" means
> the standard does
> not say anything about the implementation, and, IMHO, the
> implementors are
> free to choose the best practices.
... or to not implement anything at all.
> I think it is obviously a
> good way to
> follow BSD
Also notes the usage of "unspecified". "Unspecified" means the standard does
not say anything about the implementation, and, IMHO, the implementors are
free to choose the best practices. I think it is obviously a good way to
follow BSD.
Am I wrong?
Best regards,
Wu Yongwei
--- Original Message
This is from the glibc documentation (is glibc meaningless to the Cygwin
project?):
Function: int gettimeofday (struct timeval *tp, struct timezone *tzp)
The gettimeofday function returns the current calendar time as the elapsed
time since the epoch in the struct timeval structure indicated by tp
On Mon, Mar 25, 2002 at 10:45:09AM +0800, Wu Yongwei wrote:
>Thank you for your response, and I do see some reasonableness in your
>message. However, I can hardly calm down unless someone can answer:
>
>1) Why should Cygwin break both backward compatibility with older versions
>and compatibility L
Thank you for your response, and I do see some reasonableness in your
message. However, I can hardly calm down unless someone can answer:
1) Why should Cygwin break both backward compatibility with older versions
and compatibility Linux?
2) If ftime does not need to get timezone information, how
On Fri, Mar 22, 2002 at 06:24:00PM +0800, Wu Yongwei wrote:
>More tests show that gettimeofday has problems with timezones, too!
Calm down.
>Just terrible.
Yeah, we're mean.
int gettimeofday(struct timeval *tp, void *tzp);
DESCRIPTION
The gettimeofday() function obtains the current time
More tests show that gettimeofday has problems with timezones, too! Just
terrible.
Best regards,
Wu Yongwei
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:
Today I found this bug when running my synctime program. It always displays
the wrong timezone and thus cannot synchronize correctly. A little
investigation shows that it is ftime in cygwin1.dll that caused the problem.
This is the minimal test case:
#include
#include
int main()
{
struct t
24 matches
Mail list logo
