Mark D. Baushke writes:
> >
> > #if @HAVE_STDINT_H@
> >/* Other systems may have an incomplete . */
> > -# include @FULL_PATH_STDINT_H@
> > +# if !defined(__sgi) || [EMAIL PROTECTED]@
> > +# include @FULL_PATH_STDINT_H@
> > +# endif
> > #endif
>
> Yes. Larry suggests that the '|| [EMAIL P
> Does your system protect against duplication of
> types out of ?
No. Neither that nor in the other direction. The conflicting
(or rather: duplicated) typedefs are also not under control of
any conditional such as __STDC__ or whatever.
Both headers have the usual #ifndef brackets protecting
Hi Bruno,
The CVS forked version is getting closer to the GNULIB version.
(See below).
Bruno Haible <[EMAIL PROTECTED]> writes:
> Mark D. Baushke wrote:
> > The following two patches take a closer step toward making things work
> > under the default c89 compiler on SGI boxes.
>
> Thanks for sug
Bruno Haible writes:
>
> Mark D. Baushke wrote:
> >
> > cc-1035 cc: WARNING File = /usr/include/stdint.h, Line = 5
> > #error directive: This header file is to be used only for c99 mode
> > compilations
> >
> > #error This header file is to be used only for c99 mode compilations
>
Hi Mark,
Mark D. Baushke wrote:
> The following two patches take a closer step toward making things work
> under the default c89 compiler on SGI boxes.
Thanks for suggesting these. But IRIX 6.5 has the types defined
in and , therefore maybe some earlier
version of IRIX had them only in ? Therefo
Simon Josefsson wrote:
> The sys_socket module uses mostlyclean-local:
>
> mostlyclean-local:
> -rmdir sys 2>/dev/null
>
> This makes it difficult for other modules to do the same. I get:
>
> Makefile:817: warning: overriding commands for target `mostlyclean-local'
> Makefile:712: warning
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Marti,
I have committed a change to CVS top-of-tree that may help you.
Does your system protect against duplication of types out
of ?
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (FreeBSD)
iD8DBQFEnD0ZCg7APGsDnFERAjXSAJ9
Eric Blake-1 <[EMAIL PROTECTED]> writes:
> That thread means that the autoconf decision to obsolete
> AC_HEADER_SYS_WAIT for 2.60 may have been premature; at
> any rate, the documentation under that macro is not completely
> accurate - I'll have to forward this bug report on to autoconf as
> well.
Ralf Wildenhues writes:
>
> ...this time the percolation latency will be about as low as it gets.
Only on your end. The bottleneck is usually at the other end of the
pipeline. :-)
-Larry Jones
Physical education is what you learn from having your face in
someone's armpit right before lunch. -
Hi Ralf,
...this time the percolation latency will be about as low as it gets.
:-)
Likely so, OTOH, they are not bound together so folks will try to mix
'n match. :)
Since I don't assume I get the chance of saying this very often...
* Larry Jones wrote on Fri, Jun 23, 2006 at 07:51:37PM CEST:
> The big benefit is that it fixes the immediate problem now as opposed
> to waiting for the autoconf change to percolate out into the world.
...this time the percolatio
Paul Eggert writes:
>
> That change is obviously safe, but why is it needed? Gnulib assumes
> C89, and the preprocessors that you mention don't conform to C89.
It isn't absolutely needed, but I'd argue that it's desirable. The cost
of the change is exceeding low -- it doesn't make the code any
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ben Pfaff wrote:
>> I think you are overlooking the changes in Technical Corrigendum
>> 1, which includes the following:
>
> Thanks for the text; I don't have a copy of this Technical Corrigendum.
You can get a copy at iso.org for free.
--
"Ho ho ho. I
Eric Blake wrote:
> What should m4 do in its syscmd() macro, then? POSIX is clear; if m4
> is POSIX-compliant, then it executes the command using the POSIX
> sh (not necessarily /bin/sh, but that serves as a close approximation).
> But on non-POSIX platforms, such as mingw or OS/2, should syscmd
>
> Eric Blake asked:
> > Is it worth adding a system module to gnulib that detects
> implementations with
> > this bug, and provides rpl_system to work around it?
>
> The specification of system() in ISO C 99 does not specify
> 1) which is the command processor,
> and in particular which a
> The lib/stdint.h which is generated on an IRIX 5.3 system should have
> all of the stuff you need without any change needed to md5.c or md5.h.
>
> If you want to checkout a copy of the vanilla CVS sources and do a quick
> configure and build to let us know of any warnings or errors you see,
> th
I'm not sure whether I should really chime in.
I'm mostly sending this stuff just because "What required for SGIs?"
w.r.t. stdint/inttypes has become a current topic and this fits in.
The recent gnulib stdint_.h changes for SGIs look promising to me.
However, it'll take some days for me to check t
This is making me more and more inclined to switch to a stdint.h
replacement, not something that tries to augment existing broken
systems. It would be much simpler to maintain, I think. I'll work on
a proposal and try to have something ready in a day or two.
Ben Pfaff wrote:
> I think you are overlooking the changes in Technical Corrigendum
> 1, which includes the following:
Thanks for the text; I don't have a copy of this Technical Corrigendum.
I have changed stdint_.h and the test module accordingly.
Bruno
diff -c -3 -r1.17 stdint_.h
*** lib/std
Eric Blake asked:
> Is it worth adding a system module to gnulib that detects implementations
> with
> this bug, and provides rpl_system to work around it?
The specification of system() in ISO C 99 does not specify
1) which is the command processor,
and in particular which are the built-i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Andreas Büning on 6/22/2006 1:29 PM:
>
> However, I thought that this behaviour of system() was common on DOS/Win*/OS/2
> systems.
> system("xcopy non_existing_file") returns 1 for example.
That's not a problem, unless:
FILE*f;
int res
On Wed, 2006-06-21 at 12:03 +0200, Simon Josefsson wrote:
> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
> > Yoann Vandoorselaere <[EMAIL PROTECTED]> writes:
> >
> >> On Sat, 2006-06-17 at 21:02 +0200, Simon Josefsson wrote:
> >>> Hi Yoann! Ok to install this? Gnulib assumes that sys/types.h
>
Hi Martin,
The CVS project has forked from the GNULIB project slightly for the
stdint stuff as I have not seen any commit to gnulib to support the SGI
compilation problems we had observed. I have hopes that they will either
adopt our changes or equivalent changes so that we can once more use
their
23 matches
Mail list logo
