bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: no rpl_mktime in mktime.c


From: Paul Eggert
Subject: Re: no rpl_mktime in mktime.c
Date: Fri, 08 Jul 2005 11:46:21 -0700
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

Patrice Dumas <address@hidden> writes:

> Yes, but if in the standard headers something odd is done with the mktime 
> symbol and mktime is redefined then it could end up with a build error.

Yes; that's a problem with all the rpl_* symbols.

> It might be better than a runtime error (but not always). 

We greatly prefer build-time errors to run-time errors.

> In fact I throw this issue because I have a report that on a redhat 
> entreprise linux 3 with C++, gnulib wants to use its mktime, but in the
> C++ headers mktime is undefined and then there is a build error.

I don't know C++, but I don't see how that strategy could be
conforming.  I thought that C++ was supposed to be namespace clean
these days.  So isn't a standard C++ program supposed to be able to do
this?

#define mktime(x) (x)
#include <ctime>
int i = mktime (0);

The implementation you're talking about won't handle this program
correctly.  So perhaps you can have your users file a bug report with
their C++ supplier.  (Or perhaps I'm misunderstanding C++ -- I don't
know the language, after all.)

> maybe changing mktime to rpl_mktime
> in mktime.c doesn't help. 

That's correct; it won't help.

> I had a look at the other source files, and in many cases the function is
> called with rpl_ appended (rpl_putenv, rpl_mkstemp, rpl_mkdir....).

No, those functions are never called with rpl_ prepended.  Instead,
the usual pattern is something like this:

In config.h:

#define malloc rpl_malloc

In malloc.c:

#include <config.h>
#undef malloc
void *rpl_malloc (size_t n) { ... malloc (n) ... }

This way, only config.h and malloc.c need to know about the replacement;
all the other code.

This problem has been fixed for localtime_r in a different way, and we
could use the same method to fix it for mktime_r.  That is, we could
change the role of time_r.h to mean "act like time.h, but replace
functions that need to get fixed", and then have it "#define mktime
rpl_mktime".  Would that work for you?  If so, perhaps we should do
this sort of thing for all the rpl_* functions.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]