From: Jason Green <news AT jgreen4 DOT fsnet DOT co DOT uk>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp-workers AT delorie DOT com
Subject: Re: strftime patch
Date: Wed, 17 Jan 2001 22:18:40 +0000
Message-ID: <4j3c6t4mdg7ah2ua89oaecsl3t9rd4jr7m@4ax.com>
References: <h8k96tcnnlq0b90tduvefu93ds6vj61m2j AT 4ax DOT com> <Pine DOT SUN DOT 3 DOT 91 DOT 1010117130918 DOT 18768A-100000 AT is>
In-Reply-To: <Pine.SUN.3.91.1010117130918.18768A-100000@is>
X-Mailer: Forte Agent 1.7/32.534
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id RAA17073
Reply-To: djgpp-workers AT delorie DOT com

On Wed, 17 Jan 2001 13:13:50 +0200 (IST), you wrote:

> > FWIW, the test program I gave with the patches, has exact same
> > behaviour on my Linux setup as with DJGPP with the first patch only.
> 
> So you are in effect saying that glibc, at least the version you use, is 
> incompatible with C9x?

Leaving aside any question about the validity of using a draft
standard, all I can say is that glibc here does not produce results
according to strftime() definition for the "C" locale.

I've briefly read about locales and my understanding is that unless
there is a call at program startup to setlocale() then libc functions
should behave according to the "C" locale.  If this is the case then,
yes, the version of glibc I have is not compliant.

This is with glibc release 2.1.96.
-- 
[please cc replies if possible]