[Top][All Lists]
[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.
- no rpl_mktime in mktime.c, Patrice Dumas, 2005/07/07
- Re: no rpl_mktime in mktime.c, Paul Eggert, 2005/07/07
- Re: no rpl_mktime in mktime.c, Patrice Dumas, 2005/07/08
- Re: no rpl_mktime in mktime.c,
Paul Eggert <=
- Re: no rpl_mktime in mktime.c, Patrice Dumas, 2005/07/08
- Re: no rpl_mktime in mktime.c, Paul Eggert, 2005/07/08
- Re: no rpl_mktime in mktime.c, Patrice Dumas, 2005/07/09
- Re: no rpl_mktime in mktime.c, Paul Eggert, 2005/07/09
- Re: no rpl_mktime in mktime.c, James Youngman, 2005/07/09
- Re: no rpl_mktime in mktime.c, Patrice Dumas, 2005/07/11
- Re: no rpl_mktime in mktime.c, Paul Eggert, 2005/07/12
- Re: no rpl_mktime in mktime.c, James Gallagher, 2005/07/12
- Re: [bug-gnulib] Re: no rpl_mktime in mktime.c, Bruno Haible, 2005/07/11
- Re: [bug-gnulib] Re: no rpl_mktime in mktime.c, Paul Eggert, 2005/07/11