This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [patch libgfortran]: Fix build of libgfortran for mingw and improve POSIX ctime_r implementation
2011/1/31 Richard Guenther <richard.guenther@gmail.com>:
> On Sat, Jan 29, 2011 at 5:57 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
>> Hello,
>>
>> recent changes lead to a build failure for mingw targets in gfortran.
>> Following patch solves this.
>>
>> ChangeLog
>>
>> 2011-01-29 ?Kai Tietz
>>
>> ? ? ? ?* intrinsics/ctime.c (ctime_r): Improve implementation.
>>
>> Tested for x86_64-w64-mingw32. Ok for apply?
>>
>> Regards,
>> Kai
>>
>> Index: intrinsics/ctime.c
>> ===================================================================
>> --- intrinsics/ctime.c ?(revision 169388)
>> +++ intrinsics/ctime.c ?(working copy)
>> @@ -42,11 +42,17 @@
>>
>>
>> ?#ifndef HAVE_CTIME_R
>> +/* Make sure we don't see here a macro. ?*/
>> +#undef ctime_r
>> +
>> ?static char *
>> ?ctime_r (const time_t * timep, char * buf __attribute__((unused)))
>> ?{
>> ?#ifdef HAVE_CTIME
>> - ?return ctime (timep);
>> + ?char *tmp = ctime (timep);
>> + ?if (tmp)
>> + ? ?tmp = strcpy (buf, tmp);
>> + ?return tmp;
>
> Note that this isn't any better than returning the statically allocated
> result of ctime() (I suppose we don't free the result of ctime_r anywhere?).
> So we now create memory leaks. ?What's the problem with the original
> implementation?
>
> Richard.
>
>> ?#else
>> ? return NULL;
>> ?#endif
>>
>
ctime returns (for windows) a thread-safe pointer, which gets reused
on thread-base. So it is by default thread-safe. But as intention is
here to emulate POSIX behavior of ctime_r, well, we should do that and
not simply introduce here none-standard behavioir by ignoring the
buffer argument. Return of ctime_r shall be NULL on failure, or
address of passed buf argument.
Main issue here is the undefine of ctime_r, as this can be (and is for
mingw in combination with _POSIX) a define to emulate the POSIX
defined behavor.
Kai