Any obvious reason we shouldn't create a time.h with the contents of
the current time_r.h, using the same logic we use to replace string.h?
It would be nice to avoid '#include "time_r.h"' and just do '#include
' in my code.
/Simon
hi,
while trying to biuld the current fastjar (on savannah.nongnu.org) CVS
head on sparc-solaris-2.9 using Sun CC, I noticed that the build fails with
cc -DHAVE_CONFIG_H -I. -I.. -g -c regex.c -KPIC -DPIC -o .libs/regex.o
"./regex_internal.h", line 25: cannot find include file:
"./regex_inte
Hi, the pspp-dev@gnu.org team is wondering how to best handle the case
where a broken native snprintf implementation (e.g. on mingw)
prevents gnulib-tool from providing gnulib's C99 compatible snprintf.
-- e.g.: http://http://lists.gnu.org/archive/html/pspp-dev/2007-02/msg00043.html
Is there a re
"John McCabe-Dansted" <[EMAIL PROTECTED]> writes:
> Hi, the pspp-dev@gnu.org team is wondering how to best handle the case
> where a broken native snprintf implementation (e.g. on mingw)
> prevents gnulib-tool from providing gnulib's C99 compatible snprintf.
> -- e.g.:
> http://http://lists.gnu.o
Dalibor Topic <[EMAIL PROTECTED]> writes:
> which seems to indicate that the regex module should depend on the
> stdbool module.
The problem with having it depend on stdbool is that then applications
intended only for C99 or better would drag in stdbool unnecessarily.
That's why the dependency is
Hello,
Dalibor Topic wrote:
> while trying to biuld the current fastjar (on savannah.nongnu.org) CVS
> head on sparc-solaris-2.9 using Sun CC, I noticed that the build fails with
>
> cc -DHAVE_CONFIG_H -I. -I.. -g -c regex.c -KPIC -DPIC -o .libs/regex.o
> "./regex_internal.h", line 25: cannot
Hello Paul,
Sorry, our mails crossed. I thought it was a simple oversight.
> The problem with having it depend on stdbool is that then applications
> intended only for C99 or better would drag in stdbool unnecessarily.
> That's why the dependency isn't there now.
Packages who don't want stdbool
Simon Josefsson wrote:
> Any obvious reason we shouldn't create a time.h with the contents of
> the current time_r.h, using the same logic we use to replace string.h?
>
> It would be nice to avoid '#include "time_r.h"' and just do '#include
> ' in my code.
The full TODO list for this topic is bel
