On Jul 12, 2005, at 12:31 AM, Paul Eggert wrote:
Patrice Dumas <[EMAIL PROTECTED]> writes:
It is likely that it fixes my issue (I cannot test myself).
Hmm, if we can't test the fix then I'm tempted to leave it alone.
Do you know someone else who can test it?
I can test it. I have the cod
Patrice Dumas <[EMAIL PROTECTED]> writes:
> It is likely that it fixes my issue (I cannot test myself).
Hmm, if we can't test the fix then I'm tempted to leave it alone.
Do you know someone else who can test it?
___
bug-gnulib mailing list
bug-gnulib
I'm dropping in in the middle of this thread, but I may have some
useful information. Patrice Dumas was adding gnulib functions to
libdap, which is part of my project. We found that when building on Red
Hat Enterprise Linux 3 (Workstation) running on a dual processor x86_64
and using gcc 3.2.3,
Bruno Haible <[EMAIL PROTECTED]> writes:
> - Which header files are included by the program, in which order?
That I don't know, but it's pretty easy to see how the problem
would arise by looking at the header (see the pattern below).
> - Which C++ header undefines mktime?
On my Debian GNU/Linux
Paul Eggert wrote:
> 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
> int i = mktime (0);
No, this cannot work: will typically contain a declaration like
extern "C" {
> 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". W
On Sat, Jul 09, 2005 at 09:30:35AM +0200, Patrice Dumas wrote:
> > Unlike some of the other modules, lib/mktime.c is not a wrapper around
> > the system mktime. It is a complete reimplementation, so there's no
> > need for an "#undef mktime" or a "rpl_mktime" in lib/mktime.c itself.
>
> So maybe
Patrice Dumas <[EMAIL PROTECTED]> writes:
> So maybe there shouldn't be
> AC_DEFINE(mktime, rpl_mktime,
> in gl_FUNC_MKTIME in m4/mktime.m4?
Yes, because otherwise mktime.c would attempt to define an external
function "mktime". The C Standard doesn't allow that, and some hosts
don't permit it.
> Unlike some of the other modules, lib/mktime.c is not a wrapper around
> the system mktime. It is a complete reimplementation, so there's no
> need for an "#undef mktime" or a "rpl_mktime" in lib/mktime.c itself.
So maybe there shouldn't be
AC_DEFINE(mktime, rpl_mktime,
in gl_FUNC_MKTIME in m4
Patrice Dumas <[EMAIL PROTECTED]> writes:
> But that's not how it's done for mktime. Indeed in m4/mktime.m4 there is
> AC_DEFINE(mktime, rpl_mktime
> while in lib/mktime.c there is
>
> time_t
> mktime (struct tm *tp)
>
> and not
> time_t
> rpl_mktime (struct tm *tp)
>
> Doesn't that cause an err
> 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
> #undef malloc
> void *rpl_malloc (size_t n) { ... malloc (n) ... }
>
> This way, only config.h and m
Patrice Dumas <[EMAIL PROTECTED]> 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 al
> > There is no rpl_mktime defined in mktime.c, although in gl_FUNC_MKTIME
> > AC_DEFINE(mktime, rpl_mktime,
>
> Doesn't this cause the 'mktime' in mktime.c to be replaced by 'rpl_mktime'?
> Similarly for strtod.
Yes, but if in the standard headers something odd is done with the mktime
symb
Patrice Dumas <[EMAIL PROTECTED]> writes:
> There is no rpl_mktime defined in mktime.c, although in gl_FUNC_MKTIME
> there is
>
> AC_DEFUN([gl_FUNC_MKTIME],
> [
> AC_REQUIRE([AC_FUNC_MKTIME])
> if test $ac_cv_func_working_mktime = no; then
> AC_DEFINE(mktime, rpl_mktime,
Doesn't this caus
Hi,
There is no rpl_mktime defined in mktime.c, although in gl_FUNC_MKTIME
there is
AC_DEFUN([gl_FUNC_MKTIME],
[
AC_REQUIRE([AC_FUNC_MKTIME])
if test $ac_cv_func_working_mktime = no; then
AC_DEFINE(mktime, rpl_mktime,
[Define to rpl_mktime if the replacement function should be used.
15 matches
Mail list logo
