Am 26.05.2016 um 08:54 schrieb KOBAYASHI Shinji:
On Wed, 25 May 2016 22:02:50 +0200, Hans-Bernhard Bröker wrote:
On May 25 11:28, KOBAYASHI Shinji wrote:
- isupper is a macro which classifies ASCII integer values by table
lookup.
- It is defined only when isascii(c) is true or c is EOF.
T
On Thu, 26 May 2016 12:23:03 +0200, Corinna Vinschen wrote:
> > > A proper solution may have to be more like this:
> > > int mapped = wctob(*src);
> > > /* this call is safe now because of how wctob() works: */
> > > if (isupper(mapped)) {
> > >*dst++ = (unsigned char)mapped;
>
On May 26 15:54, KOBAYASHI Shinji wrote:
> On Wed, 25 May 2016 22:02:50 +0200, Hans-Bernhard Bröker wrote:
> > On May 25 11:28, KOBAYASHI Shinji wrote:
> >> The intention of the following code in tzsetwall() should be to pick
> >> up UPPERCASE letters "in ASCII range":
> > Are you sure you're not m
On Wed, 25 May 2016 22:02:50 +0200, Hans-Bernhard Bröker wrote:
> On May 25 11:28, KOBAYASHI Shinji wrote:
>> The intention of the following code in tzsetwall() should be to pick
>> up UPPERCASE letters "in ASCII range":
> Are you sure you're not mixing ASCII with '8-bit character' range there?
I'
Am 25.05.2016 um 10:44 schrieb Corinna Vinschen:
On May 25 11:28, KOBAYASHI Shinji wrote:
Any other comments on this topic? Let me explain my proposal again.
The intention of the following code in tzsetwall() should be to pick
up UPPERCASE letters "in ASCII range":
Are you sure you're not mi
On May 25 11:28, KOBAYASHI Shinji wrote:
>
> Any other comments on this topic? Let me explain my proposal again.
>
> The intention of the following code in tzsetwall() should be to pick
> up UPPERCASE letters "in ASCII range":
>
> if (isupper(*src)) *dst++ = *src;
>
> NOTE: src is wchar_t *, ds
Any other comments on this topic? Let me explain my proposal again.
The intention of the following code in tzsetwall() should be to pick
up UPPERCASE letters "in ASCII range":
if (isupper(*src)) *dst++ = *src;
NOTE: src is wchar_t *, dst is char *.
As Csaba Raduly pointed out, isw*() functions
Hi,
> Csaba Raduly wrote:
> If the type of those members is WCHAR[] then using isascii() /
> isupper() on them is just plain wrong.
> The correct function to use would be iswupper().
I agree that isw*() functions should be used for wchar_t. But I think
just changing isupper() to iswupper()
On Fri, May 20, 2016 at 6:22 AM, KOBAYASHI Shinji wrote:
(snip)
>
> localtime() calls tzsetwall() when TZ is not set. In tzsetwall(),
> the StandardName and DaylightName member values retrieved by
> GetTimeZoneInformation() are checked with isupper() and copied to the
> char[] buf
>>>>> Warren Young wrote:
> How about you just give the line of code and explain what’s wrong with it?
> Then someone with checkin rights can reimplement your change from your prose
> description.
Thank you for your suggestion. So I try to describe the problem:
change in regards to the C localtime function since 2007?
I've got a program with a function that uses it to present the date and
time that I just changed. The time isn't appearing only the date.
strlen is based on the current contents of the array ... it stops
at the first null. So it&#
On 06/15/2011 2:46 PM, Georg Nikodym wrote:
On 2011-06-15, at 2:04 PM, Tod wrote:
Ok, right - duh. Let me back up a couple of steps.
I'm passing a 128 byte char array. I allocated it to provide enough room for
the date/time stamp this function is returning. strlen(tout) will resolve to
t
On 2011-06-15, at 2:04 PM, Tod wrote:
> Ok, right - duh. Let me back up a couple of steps.
>
> I'm passing a 128 byte char array. I allocated it to provide enough room for
> the date/time stamp this function is returning. strlen(tout) will resolve to
> the length of the tout string.
>
> Yo
On Wed, 15 Jun 2011, Tod wrote:
I'm passing a 128 byte char array. I allocated it to provide enough room for
the date/time stamp this function is returning. strlen(tout) will resolve to
the length of the tout string.
You said above that I shouldn't be using strlen(tout) and instead I should
localtime function since 2007?
I've got a program with a function that uses it to present the date and
time that I just changed. The time isn't appearing only the date.
No errors, no dumps, just no time. Most bizarre.
TIA - Tod
Incidentally, here's how I'm valuing the time.
On Wed, Jun 15, 2011 at 01:45:03PM -0400, Tod wrote:
>On 06/15/2011 1:38 PM, Christopher Faylor wrote:
>> On Wed, Jun 15, 2011 at 01:23:05PM -0400, Tod wrote:
>>> On 06/15/2011 11:26 AM, Tod wrote:
>>>> Hi,
>>>>
>>>> Has anything change in reg
On 06/15/2011 1:38 PM, Christopher Faylor wrote:
On Wed, Jun 15, 2011 at 01:23:05PM -0400, Tod wrote:
On 06/15/2011 11:26 AM, Tod wrote:
Hi,
Has anything change in regards to the C localtime function since 2007?
I've got a program with a function that uses it to present the date and
time
On Wed, Jun 15, 2011 at 01:23:05PM -0400, Tod wrote:
>On 06/15/2011 11:26 AM, Tod wrote:
>> Hi,
>>
>> Has anything change in regards to the C localtime function since 2007?
>> I've got a program with a function that uses it to present the date and
>> ti
On 06/15/2011 11:26 AM, Tod wrote:
Hi,
Has anything change in regards to the C localtime function since 2007?
I've got a program with a function that uses it to present the date and
time that I just changed. The time isn't appearing only the date.
No errors, no dumps, just no
Hi,
Has anything change in regards to the C localtime function since 2007?
I've got a program with a function that uses it to present the date and
time that I just changed. The time isn't appearing only the date.
No errors, no dumps, just no time. Most bizarre.
TIA - Tod
On 10/30/2010 3:24 PM, Christopher Faylor wrote:
This should be fixed in the next snapshot.
Confirmed. Thanks. And this fixes the timezone bug that's described in
/usr/share/doc/Cygwin/emacs.README. The workaround given there
(defining TZ before starting emacs) is no longer necessary.
Ke
On Sat, Oct 30, 2010 at 01:53:11PM -0400, Ken Brown wrote:
>How's the attached patch? I'm not set up to build cygwin1.dll, so I
>can't test it right now. I hope the intent is clear in case I got
>something wrong.
That would do it, yes. I chose to just track the initialization state
in lcl_is_
On 10/30/2010 8:58 AM, Ken Brown wrote:
I've looked at Cygwin's localtime.cc, and the behavior I'm complaining
about is caused by the following code at the beginning of tzset:
const char *name = getenv("TZ");
if (name == NULL) {
if (!lcl_is_set)
urces.)
Probably worth pointing it out to the emacs upstream, then :)
But I get the same behavior with the following revised test case:
#include
#include
int
main (void)
{
time_t now = time ((time_t *) 0);
printf ("TZ is initially unset; hour = %d\n", localtime (&now)->
emacs upstream, then :)
But I get the same behavior with the following revised test case:
#include
#include
int
main (void)
{
time_t now = time ((time_t *) 0);
printf ("TZ is initially unset; hour = %d\n", localtime (&now)->tm_hour);
putenv ("TZ=GMT0");
same behavior with the following revised test case:
#include
#include
int
main (void)
{
time_t now = time ((time_t *) 0);
printf ("TZ is initially unset; hour = %d\n", localtime (&now)->tm_hour);
putenv ("TZ=GMT0");
printf ("TZ=GMT0; hour = %d\n", l
wing revised test case:
>
> #include
> #include
>
> int
> main (void)
> {
> time_t now = time ((time_t *) 0);
> printf ("TZ is initially unset; hour = %d\n", localtime (&now)->tm_hour);
> putenv ("TZ=GMT0");
> printf ("TZ=G
On 10/29/2010 5:58 PM, Eric Blake wrote:
> On 10/29/2010 03:54 PM, Eric Blake wrote:
>> On 10/29/2010 03:44 PM, Ken Brown wrote:
>>> While trying to debug a timezone problem in the Cygwin build of emacs, I've
>>> come across a difference between Cygwin and Linux i
On 10/29/2010 03:54 PM, Eric Blake wrote:
> On 10/29/2010 03:44 PM, Ken Brown wrote:
>> While trying to debug a timezone problem in the Cygwin build of emacs, I've
>> come across a difference between Cygwin and Linux in the behavior of
>> localtime with respect to T
Dear Ken --
You've described a *difference*, but it's not
clear to me that it's a *bug*. Some run-time
libraries cache values and some don't ...
Now if the Posix spec says it *must* act a
particular way and cygwin has it wrong, that's
a bit of a different story
Regards -- Eliot Moss
--
P
On 10/29/2010 03:44 PM, Ken Brown wrote:
> While trying to debug a timezone problem in the Cygwin build of emacs, I've
> come across a difference between Cygwin and Linux in the behavior of
> localtime with respect to TZ. Suppose I set TZ, call localtime, unset TZ,
> and cal
While trying to debug a timezone problem in the Cygwin build of emacs, I've
come across a difference between Cygwin and Linux in the behavior of localtime
with respect to TZ. Suppose I set TZ, call localtime, unset TZ, and call
localtime again. On Cygwin, the second call to localtime re
On Sun, Jul 10, 2005 at 05:06:12PM -0400, Brian Bisaillon wrote:
>This works...
>
>struct tm *sci_localtime (time_t timep) {
>struct tm *result;
> if ((result = localtime(&timep)) == NULL) {
>int errsv = errno;
>fprintf (stderr, "\nError Code %i:
This works...
struct tm *sci_localtime (time_t timep) {
struct tm *result;
if ((result = localtime(&timep)) == NULL) {
int errsv = errno;
fprintf (stderr, "\nError Code %i: %s at line
%i of %s function in %s \
\n", strerror (errsv), 2,
&q
On Thu, Dec 16, 2004 at 04:52:48PM -0800, Till Immanuel Patzschke wrote:
>the problem occurs in a multithreaded program, but only one thread
>calling gmtime_r (calling localtime_r locks as well). The other tread
>calls gettimeofday/time. The thread calling gmtime_r is stalled
>completely. Mac
Hello,
the problem occurs in a multithreaded program, but only one thread
calling gmtime_r (calling localtime_r locks as well). The other tread
calls gettimeofday/time. The thread calling gmtime_r is stalled
completely. Machine is XP SP2.
I've tested this problem on multiple machines (w/ dif
Yitzchak Scott-Thoennes wrote:
On Thu, Mar 18, 2004 at 07:26:03PM -0800, Andrew DeFaria wrote:
I'm observing the following:
C09-272-A:date
Thu Mar 18 19:22:53 PST 2004
C09-272-A:perl -e 'print scalar (localtime) . "\n"'
Fri Mar 19 03:22:58 2004
C09-272-A:ccperl -e
On Thu, Mar 18, 2004 at 07:26:03PM -0800, Andrew DeFaria wrote:
> I'm observing the following:
>
> C09-272-A:date
> Thu Mar 18 19:22:53 PST 2004
> C09-272-A:perl -e 'print scalar (localtime) . "\n"'
> Fri Mar 19 03:22:58 2004
> C09-272-A:ccperl -e &#x
I'm observing the following:
C09-272-A:date
Thu Mar 18 19:22:53 PST 2004
C09-272-A:perl -e 'print scalar (localtime) . "\n"'
Fri Mar 19 03:22:58 2004
C09-272-A:ccperl -e 'print scalar (localtime) . "\n"'
Thu Mar 18 19:23:03 2004
C09-272-A:type -p p
> seconds you add or remove accordingly.
>
> [code]
> use Time::Local;
> print "GM: " . gmtime() . "\n";
> print "Local: " . localtime() . "\n";
> if (gmtime() eq localtime()) {
> print "GM time and localtime are the same!\n"
> -Original Message-
> From: cygwin-owner at cygwin dot com
> [mailto: cygwin-owner at cygwin dot com] On Behalf Of Keith Bainbridge
> Sent: Thursday, March 04, 2004 6:35 PM
> To: The Cygwin Mailing List
> Subject: Re: perl 5.8.2's localtime reports gmtime
&g
Steve Kelem wrote:
> I'm running the latest cygwin, including perl 5.8.2:
> % perl -version
>
> This is perl, v5.8.2 built for cygwin-thread-multi-64int
Ug. Read the archives. This has come up several times in the last
couple of weeks, it's a known bug that will be fixed in the next Cygwin
DLL
Steve Kelem wrote:
> I'm running the latest cygwin, including perl 5.8.2:
> % perl -version
>
> This is perl, v5.8.2 built for cygwin-thread-multi-64int
Ug. Read the archives. This has come up several times in the last
couple of weeks, it's a known bug that will be fixed in the next Cygwin
DLL
I'm running the latest cygwin, including perl 5.8.2:
% perl -version
This is perl, v5.8.2 built for cygwin-thread-multi-64int
When I use localtime, I get the same result as gmtime:
% perl -e 'print scalar gmtime, "\n", scalar localtime, "\n"'
Mon Mar 1 06:18:07
On Sun, Feb 29, 2004 at 02:52:34AM -0800, Yitzchak Scott-Thoennes wrote:
> On Sat, Feb 28, 2004 at 08:13:39PM -0500, Brian Kelly wrote:
^^^
Sorry about that; I *thought* I had it set up to not include email addrs.
--
Unsubscribe info:
On Sat, Feb 28, 2004 at 08:13:39PM -0500, Brian Kelly <[EMAIL PROTECTED]> wrote:
> A cursory check of the archives would have dug up this exchange:
>
> http://sources.redhat.com/ml/cygwin/2004-02/msg00582.html
>
> Sooo - either try the latest snapshot of the cygwin1.dll, or
> wait for release 1.5
EMAIL PROTECTED] On Behalf
Of Charles Plager
Sent: Saturday, February 28, 2004 7:35 PM
To: Cygwin Mailing list
Subject: localtime() acting like gmtime() in Perl
Hello,
localtime() seems to be returning GMT instead of the local
time. I've
tested the same script on three differen
Hello,
localtime() seems to be returning GMT instead of the local time. I've
tested the same script on three different machines. (Unfortunately, on
linux and sgi, they are using perl 5.6.1 whereas on cygwin, I'm using
5.8.2, but I don't *think* it's a perl bug). If
Hello Kenneth,
SK> I haven't seen closure on this subject yet. I too have the same
SK> problem.
PTA.
--
Mit freundlichen Grüssen
Gerrit P. Haase
mailto:[EMAIL PROTECTED]
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
I haven't seen closure on this subject yet. I too have the same problem.
--
Ken Shaffer
- - - - - - - Appended by Scientific-Atlanta, Inc. - - - - - - -
This e-mail and any attachments may contain information which is confidential,
proprietary, privileged or otherwise protected by l
as to go back to 5.6.
Based on the other postings I believe it is a Cygwin specific issue.
perl -e 'use POSIX; print strftime("%H:%M:%S", localtime) . "\n";'
This always returns GMT time with 5.8, but returns local time with 5.6.
Please keep 5.6 available as l
After that i did find symptomatic insane behaviour of "local" function.
> > > Now it returns GMT time.
> > > Does anybody unite with me ?
> >
> > Yes, it is wrong here too.
> >
> > > ----
Now it returns GMT time.
> > Does anybody unite with me ?
>
> Yes, it is wrong here too.
>
> >
> > $perl -e 'use POSIX qw(strftime); $now_string = strftime ("%a %b %e
> > %H:%M:%S %Y&quo
time.
> Yes, it is wrong here too.
>
> >
> > $perl -e 'use POSIX qw(strftime); $now_string = strftime ("%a %b %e
> > %H:%M:%S %Y", localtime); print $now_string . "\n";
, it is wrong here too.
>
> $perl -e 'use POSIX qw(strftime); $now_string = strftime ("%a %b %e
> %H:%M:%S %Y", localtime); print $now_string . "\n";'
> Sun Nov
("%a %b %e
%H:%M:%S %Y", localtime); print $now_string . "\n";'
Sun Nov 9 15:06:30 2003
$ date -R
Sun, 09 Nov 2003 17:06:33 +0200
Kirill.
--
Unsubscribe info: http://cygwin.com/ml/#unsubs
/ Igor Pechtchanski <[EMAIL PROTECTED]> wrote:
|> [...]
|> Program received signal SIGSEGV, Segmentation fault.
|> 0x6100d074 in cygwin_attach_handle_to_fd () from /usr/bin/cygwin1.dll
[...]
| I was unable to reproduce your problem on Win2k SP2 (cygwin-1.3.20-1). I
| used the attached program. It
On Sun, 23 Feb 2003, Marco Giovannini wrote:
> I've got this simple piece of code:
>
> time_t current_time;
> struct tm *boot_time;
> current_time = time(NULL);
> boot_time = localtime(¤t_time);
>
> that is very stupid and *should* run on every posix machine, but..
I've got this simple piece of code:
time_t current_time;
struct tm *boot_time;
current_time = time(NULL);
boot_time = localtime(¤t_time);
that is very stupid and *should* run on every posix machine, but..
with the latest cygwin dll release (1.3.20) I receive this error:
Program received s
59 matches
Mail list logo
