This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, libgfortran] PR 61310 CTIME intrinsic output incorrect on MinGW
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 26 May 2014 04:41:03 -0700
- Subject: Re: [PATCH, libgfortran] PR 61310 CTIME intrinsic output incorrect on MinGW
- Authentication-results: sourceware.org; auth=none
- References: <CAO9iq9HQvTKd_eLrh=uR0sQx9=1Y1JTkapYuaFWR2xsncbSAtg at mail dot gmail dot com> <20140525222511 dot GA32519 at troutmask dot apl dot washington dot edu> <CAO9iq9Hk0O+xU0GidRMDmbOqGLuc6jzFmbgTzvh+EW8708znEw at mail dot gmail dot com>
On Mon, May 26, 2014 at 01:00:56PM +0300, Janne Blomqvist wrote:
> On Mon, May 26, 2014 at 1:25 AM, Steve Kargl
> <sgk@troutmask.apl.washington.edu> wrote:
> > On Mon, May 26, 2014 at 12:21:21AM +0300, Janne Blomqvist wrote:
> >> Hi,
> >>
> >> GFortran currently uses strftime(...,"%c",...) to produce the result
> >> for the CTIME and FDATE intrinsics. Unfortunately, it seems that on
> >> MinGW this does not produce identical output to the C stdlib ctime(),
> >> even in the default locale.
> >>
> >> The attached patch implements an alternative approach, originally
> >> suggested by Jakub in PR 47802, to produce a thread-safe ctime-like
> >> function by using snprintf manually.
> >>
> >> Regtested on x86_64-unknown-linux-gnu, Ok for trunk/4.9/4.8/4.7?
> >>
> >
> > Patch looks ok to me.
> >
> >> +/* Maximum space a ctime-like string might need. A "normal" ctime
> >> + string is 26 bytes, but the maximum possible year number is
> >> + 2,147,485,547 (2,147,483,647 + 1900, since tm_year is a 32-bit
> >> + signed integer) so an extra 6 bytes are needed. */
> >> +#define CSZ 32
> >
> > Is there a better name than CSZ, which is not exactly too descriptive?
>
> Hmm, what about CTIME_BUFSZ? Ok with that change?
>
Yes, the name is much better. Yes, patch is ok.
--
Steve