Paul Eggert <[EMAIL PROTECTED]> writes:
> You're welcome. One thing I forgot to mention: the old m4/socklen.m4
> code is obviously incorrect because of the stray parenthesis in this
> line:
>
> #endif)
>
> That parenthesis is copied into the C header used for testing.
>
> GCC doesn't mind, but ot
ould presumably have LGPL'd build tools also. I wonder if there
should be two separate fields.
(In practice, of course, I don't know whether this matters.)
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
___
bug-gnulib mailin
Simon Josefsson <[EMAIL PROTECTED]> writes:
> has ULONG_MAX in limits.h but not in stdlib.h. I believe C89 it to be
> in stdlib.h.
I don't think so. In a quick search through C99, I only saw
ULONG_MAX mentioned as being defined in . I don't
think C89 was different.
--
"[Modern] war is waged b
'd expect that at least one of the entries here should mention
what was actually done to the license.
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
r that can be represented in the type with smaller size.
...
22. In a two's-complement representation, there is no actual
change in the bit pattern except filling the high-order bits
with copies of the sign bit if the unsigned inte
[EMAIL PROTECTED] (Karl Berry) writes:
> ... so I would have expected it to know to use gnulib/lib and gnulib/m4,
> not lib/ and /m4. It's been a while, but my memory is that it did read
> the configure.ac settings last time I tried it.
I don't think it does anymore. I had to change my build se
The intprops.h header file seems pretty useful by itself. Would
it make sense to create a module that just imports that header
file?
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http
Paul Eggert <[EMAIL PROTECTED]> writes:
> I recently redisovered the fact that actime_r and ctime_r, like
> asctime and ctime, are unsafe functions in the same sense that gets is
> unsafe: they can overrun their output buffers and there's no simple
> way for the user to detect in advance whether t
Ben Pfaff <[EMAIL PROTECTED]> writes:
> I'm not sure I understand the fwriteerror() interface. As I read
> the function comment, fwriteerror() should always close the
> stream provided to it (except in the case of stdout). But the
> implementation does not close the
linebreak.h declares locale_charset() directly, but the latter
has its own header localcharset.h, so it seems like it should
just #include that directly.
--
"doe not call up Any that you can not put downe."
--H. P. Lovecraft
___
bug-gnulib mailing lis
;contents is" is not quite grammatical, and the comment is a
> bit overconfident about getting the "same errno".
For what it's worth, I do find Paul's version to be a little more
readable.
Bruno, thanks for looking at this.
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
gnulib-tool appears to blindly sort the list of #include
directives it prints. When the list contains #if...#endif, that
makes the output funny, e.g.:
You may need to add #include directives for the following .h files.
#endif
#if HAVE_MBRTOWC
#if HAVE_WCHAR_H && HAVE_WCTYPE_
efine va_copy(DST, SRC) __va_copy (DST, SRC)
#else
#define va_copy(DST, SRC) ((DST) = (SRC))
#endif
#endif
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
Bruno Haible <[EMAIL PROTECTED]> writes:
> Paul Eggert wrote:
>> > In other places I used to define WIN32 as an abbreviation of
>> > defined _WIN32 || defined __WIN32__
>> > Now I'm renaming that to WIN32_NATIVE.
>>
>> Would WOE32_NATIVE be a better name?
>
> Many people believe code should b
Bruno, that's great work. I did some proofreading and found some
minor things to point out.
Bruno Haible <[EMAIL PROTECTED]> writes:
> + @code{basename} assumes file names in POSIX syntax; it does not with file
> + names in Windows syntax.
"...does not" work "with file..."
> + @item btowc
> +
Gnulib includes a module for ssize_t, but it doesn't ensure that
SSIZE_MAX is available. It seems that an ssize_t.h header file
with the following contents would be sufficient:
#include
#ifndef SSIZE_MAX
# define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2))
#endif
A few of the source f
Ben Pfaff <[EMAIL PROTECTED]> writes:
> Gnulib includes a module for ssize_t, but it doesn't ensure that
> SSIZE_MAX is available. It seems that an ssize_t.h header file
> with the following contents would be sufficient:
I really meant ssize_max.h, analogous to size_max.
Paul Eggert <[EMAIL PROTECTED]> writes:
> Ben Pfaff <[EMAIL PROTECTED]> writes:
>
>> I really meant ssize_max.h, analogous to size_max.h. Or they
>> could be combined into one header file.
>
> I think size_max.h is there only because SIZE_MAX is in different
Bruno Haible <[EMAIL PROTECTED]> writes:
> However, 7.18.4 wants macros that expand to integer constants that
> are of type int_leastN_t or uint_leastN_t. But integer constants
> don't contain casts (section 6.4.4.1) - therefore it is impossible
> to write down integer constants of type, say, int_
sion.
I was under the impression that gnulib targets C89 and above,
making this a non-issue.
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
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 is
Paul Eggert <[EMAIL PROTECTED]> writes:
> Here's a proposed rewrite of the stdint module that attempts to
> simplify the module while addressing the porting issues that have come
> up in the last week. The basic idea is to use macros instead of
> typedefs. I think this kind of approach would hav
Bruno Haible <[EMAIL PROTECTED]> writes:
> /* Create a temporary directory.
>PREFIX is used as a prefix for the name of the temporary directory. It
>should be short and still give an indication about the program.
>Return a fresh 'struct temp_dir' on success. Upon error, an error messa
Bruno Haible <[EMAIL PROTECTED]> writes:
> 1) The practical reason is that while developing libsigsegv, I noticed that
> C does not have the notion of a "barrier": In code like this:
>
> set_up_datastructures();
> /* HERE I would like a barrier */
> signal(sig,my_signal_handler);
eceives the
same level of review as the standard itself):
If it is necessary to access a non-volatile object using
volatile semantics, the technique is to cast the address of
the object to the appropriate pointer-to-qualified type,
then dereference that pointer.
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
Paul Eggert <[EMAIL PROTECTED]> writes:
> Ben Pfaff <[EMAIL PROTECTED]> writes:
>
>> This is a particularly pessimistic interpretation of the
>> standard,
>
> You think _I'm_ pessimistic! You should hear Nick MacLaren and Dave
> Butenof.
Paul Eggert <[EMAIL PROTECTED]> writes:
> Ben Pfaff <[EMAIL PROTECTED]> writes:
>
>> The issue at hand, as I understand it, is not even the general
>> behavior of signals. It is the behavior of fatal signals. That
>> is, a the program terminates without ever
Paul Eggert <[EMAIL PROTECTED]> writes:
> With Bison I wanted fopen_safer but not tmpfile_safer (I think tmpfile
> is not that safe due to signals and whatnot), so I split the fopen-safer
> module into two, as follows:
Can you expand on why tmpfile is not so safe?
--
Ben Pfaff
Eric Blake <[EMAIL PROTECTED]> writes:
> According to Ben Pfaff on 7/25/2006 11:21 AM:
>> Can you expand on why tmpfile is not so safe?
>
> I'd still like to fear Paul's reasons.
I hope you mean "hear" them :-)
> But one of mine is that tmpfile is a
? It only updates code
inside an #ifdef _LIBC block.
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
t;, message);
and similarly for verror_at_line?
> + free (message);
> +}
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
Bruno Haible <[EMAIL PROTECTED]> writes:
> The "nearly an ASCII extension" assumption is so ubiquitous, think of
> (c >= '0') tests and similar. You really find it's worth mentioning?
Digits are a very special case, because the C standard (C89
onward) guarantees that they are in order and contigu
I am considering using a 64-bit type in one bit of code in GNU
PSPP. I could avoid it, but using it makes the code easier to
read. Is anyone aware of an implementation (on which GNU
programs are commonly used) that does not support a 64-bit or
wider integer type?
I'm aware that MSVC doesn't supp
is
> good enough for now.
z and t can easily be handled by casting, but j cannot. However,
for intmax_t you can use PRIdMAX. For that matter, for ptrdiff_t
you can use PRIdPTR, which makes it a little bizarre that there
is no PRIuSIZE (I like the suggestion that someone made of
creating one
Davide Angelocola <[EMAIL PROTECTED]> writes:
> I'm proposing another new module for gnulib: split.
>
> The function signature is:
> char *split(const char *str, char sep, int *argc);
>
> what do you think about?
What does it do?
--
"Sanity is not statistical."
--George Orwell
Davide Angelocola <[EMAIL PROTECTED]> writes:
> On Tuesday 05 September 2006 22:01, Ben Pfaff wrote:
>> Davide Angelocola <[EMAIL PROTECTED]> writes:
>> > I'm proposing another new module for gnulib: split.
>> >
>> > The function signature
ETTEXT_OPTIONS variable, but your message tells me
to do so and gives the right syntax.
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> Why can we assume setlocale exists?
>> Is it POSIX?
>
> Even more: It's specified by ISO C 99.
Even more than that: it's in C90 also.
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
Bruno Haible <[EMAIL PROTECTED]> writes:
> + /* GCC supports variable-size arrays in C and C++ mode.
> +ISO C++ supports variable-size arrays, but some older PGI and Sun
> compilers
> +don't. */
I don't understand this assertion that ISO C++ supports
variable-size arrays. ISO C++98 sho
l%
> + if any writes failed, change the exit status. This is
> + implemented in the Gnulib module "closeout". */
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> Karl Berry wrote:
>>> the gnulib module exit, to ensure the existence of EXIT_SUCCESS.
>>
>> Isn't it part of some sufficiently-old standard so that it's not
>> necessary/recommended?
>
> What is "it"? Using EXIT_SUCCESS, using gnulib to ensure that yo
n integral type, so it
should be supported.
Are there actual implementations that support long long int but
not its use as a switch expression?
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
Simon Josefsson <[EMAIL PROTECTED]> writes:
> I agree in general, although I'd prefer to see gnulib support autoconf
> 2.60a, automake 1.10 and gettext 0.15 for some time more, because that
> is what is installed on my up-to-date Debian 'unstable' box.
Somehow I missed the release of Autoconf 2.6
be likely.
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ben Pfaff wrote:
>> C99 added some useful functions to math.h, such as trunc and
>> round. Would there be objections to a module that adds
>> implementations of those functions?
>
> This would be a good idea. Can
tests/test-base64.c in the gnulib repository checks out marked
executable for me. Seems odd.
--
"I didn't say it was your fault.
I said I was going to blame it on you."
+ along with this program; if not, write to the Free Software Foundation,
+ Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+ Written by Paul Eggert and Ben Pfaff. */
+
+#include
+
+#if !HAVE_ROUNDF
+float
+roundf (float x)
+{
+ return round (x);
+}
+#endif /* !HAV
Bruno Haible <[EMAIL PROTECTED]> writes:
> You need to upgrade to autoconf 2.61. The signature of AC_COMPUTE_INT has
> changed between 2.60a and 2.61. (Such a change is normal. There is no
> promise of an API compatibility for a snapshot version of autoconf.)
For what it's worth, I hadn't realize
Bruno Haible <[EMAIL PROTECTED]> writes:
> Huh? I think there is a misunderstanding. The GNU standards don't want
> 'pathname' to occur in the documentation in the sense as POSIX uses it,
> because of the PATH variable and the concept of search paths. Paul then
> doesn't want to use 'pathname' in
akefile.am:
TESTS += test-arcfour$(EXEEXT)
check_PROGRAMS += test-arcfour
Any idea what I'm doing wrong?
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> * Ben Pfaff wrote on Fri, Dec 15, 2006 at 02:31:46AM CET:
>> I finally got back to working on the proposed module and
>> I'm trying to figure how tests in Gnulib work. In particular,
>> I'm confused that
ad, write `1996, 1997, 1998'. Do write each
relevant year as a four-digit number. In the normal course of
maintenance, you may come across copyright notices which omit the
century, as in `1996, 97, 98'--change these to include the century.
However, there is no need to
I didn't look to see that
specific features supported by GNU SSL are also supported by GSL.
GSL is actively maintained. It is in active use by other
projects. I can't speak for GNU SSL.
GNU SSL has C and C++ interfaces. GSL has only a C interface (as
far as I know).
--
Ben Pfaff
[EMAIL PROTECTED]
http://benpfaff.org
t might be a problem, too, but this is the one that is
causing problems for PSPP right now.
Thanks for gnulib!
--
Ben Pfaff
[EMAIL PROTECTED]
http://benpfaff.org
t;a.a_wide_char = va_arg (args, wint_t);
break;
#endif
I see that in other cases in that file where the type passed to
va_arg is likely to be narrower than int, "int" is what is passed
to va_arg as the type. Should the same tactic be used here?
--
Ben Pfaff
[EMAIL PROTECTED]
http://benpfaff.org
Bruno Haible <[EMAIL PROTECTED]> writes:
> Thanks for reporting this. This is already fixed in gnulib for 6 months:
I thought I'd done a "cvs update" recently, but obviously not.
Thanks for taking the time to reply.
--
Ben Pfaff
[EMAIL PROTECTED]
http://benpfaff.org
BILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software Foundation,
+ Inc., 51 Franklin Street, Fifth Floor, B
Bruno Haible <[EMAIL PROTECTED]> writes:
> So, to test whether native Woe32 API is available, use
>
> defined _WIN32 || defined __WIN32__
Ben Pfaff <[EMAIL PROTECTED]> writes:
> +
you elaborate, please? clean-temp guarantees that the file will be
> removed in most cases. You want it removed earlier, as soon as the fclose
> happens? To save disk space?
Yes: PSPP uses temporary files for transposing big matrices,
out-of-core merge sorting, and so on, so it's a good idea to free
up disk space when it can.
--
Ben Pfaff
[EMAIL PROTECTED]
http://benpfaff.org
Pre-C99 versions of snprintf often had an interface different
from the C99 interface: they would return -1 when the buffer was
too small, and the "size" argument was not necessarily
interpreted the same way. However, the current Gnulib snprintf
module doesn't check whether snprintf is C99-complian
intf.
We could of course test whether the system is Windows, using
#if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
or similar. Is that a better idea?
--
Ben Pfaff
[EMAIL PROTECTED]
http://benpfaff.org
Paul Eggert <[EMAIL PROTECTED]> writes:
> Ben Pfaff <[EMAIL PROTECTED]> writes:
>
>> We could of course test whether the system is Windows, using
>> #if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
>> or similar. Is that a bette
t; OK. So I'm adding Ben's module, with the following modifications:
Thank you Bruno. The changes look good to me, and they test out
correctly in PSPP.
I have not yet signed papers for gnulib contributions. Should I?
--
Ben Pfaff
[EMAIL PROTECTED]
http://benpfaff.org
pathname.h and dirname.h define macros with the same names, but
conflicting definitions. Should they be merged?
--
Ben Pfaff
[EMAIL PROTECTED]
http://benpfaff.org
The file lib/progreloc.c is not in any module (as far as I can
tell). Also, there is no header file that prototypes its
functions. Is this intentional?
--
Ben Pfaff
[EMAIL PROTECTED]
http://benpfaff.org
Ben Pfaff <[EMAIL PROTECTED]> writes:
> The file lib/progreloc.c is not in any module (as far as I can
> tell). Also, there is no header file that prototypes its
> functions. Is this intentional?
The latter I've now noticed I'm wrong about, but I'm still prett
ome things. That's an issue e.g. with Windows's %I64d
> versus %lld, and with C99 formats like %a.
I'd be very pleased to have a full C99 printf in gnulib, mainly
because I'm getting tired of not being able to write %zu to print
a size_t.
--
Ben Pfaff
[EMAIL PROTECTED]
http://benpfaff.org
///usr/lib/gcc/i586-mingw32msvc/3.4.5/../../../../i586-mingw32msvc/include/string.h:103:
warning: no previous prototype for 'strncasecmp'
[EMAIL PROTECTED]:~/pspp/mingw/pspp/_mingw/gl(0)$
Sorry about the overlong lines.
--
Ben Pfaff
[EMAIL PROTECTED]
http://benpfaff.org
Albert Chin <[EMAIL PROTECTED]> writes:
> Huh? So, if vsnprintf() exists, you assume it's C99-compliant? glib
> has a check for this, AC_FUNC_VSNPRINTF_C99, because that's not the
> case on some systems. And, we found that Solaris and AIX 5.1 do not
> have a C99-compliant vsnprintf(). The attached
Albert Chin <[EMAIL PROTECTED]> writes:
> On Mon, Feb 19, 2007 at 03:53:10PM -0800, Ben Pfaff wrote:
>> Albert Chin <[EMAIL PROTECTED]> writes:
>>
>> > Huh? So, if vsnprintf() exists, you assume it's C99-compliant? glib
>> > has a check for t
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ben Pfaff wrote:
>> The file lib/progreloc.c is not in any module (as far as I can
>> tell).
>
> Yes [1]. This "relocatable" stuff is in a temporary state. Ideally it should
> be integrated into autoconf and au
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ben Pfaff wrote on Friday/Saturday:
>> The following patch attempts to remedy the situation.
>
> I cannot see the big picture in this change. You want a snprintf() whose
> return value is correct but which still doesn't sup
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ben Pfaff asked:
>> I have not yet signed papers for gnulib contributions. Should I?
>
> Yes, please. Not only for tmpfile, but also for your future contributions.
OK. I filled out and emailed request-assign.future to
[EMAI
to math_.h, so that there's no need
for an additional #include "isnan.h"?
--
Ben Pfaff
[EMAIL PROTECTED]
http://benpfaff.org
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ben Pfaff asked:
>> >* lib/isnan.h: New file.
>> Could/should this be merged into math_.h, so that there's no need
>> for an additional #include "isnan.h"?
>
> If many other modules want isnan()
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ben Pfaff wrote:
>> I was under the impression that some platforms were missing isnan
>> entirely, so that this was worth more than just "isnan() without
>> libm". But I can't confidently name a system that lack
Paul Eggert <[EMAIL PROTECTED]> writes:
> Ben Pfaff <[EMAIL PROTECTED]> writes:
>
>> pathname.h and dirname.h define macros with the same names, but
>> conflicting definitions. Should they be merged?
>
> Well, if you want my biased opinion, pathname should g
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ben Pfaff wrote:
>> Here is my attempt at a minimally invasive resolution of the
>> differences
>
> This is backwards. You introduce a dependency from a simple module to a
> complicated module. The purpose of 'filen
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> * Bruno Haible wrote on Sun, Feb 25, 2007 at 09:23:09PM CET:
>>
>> > * It looks like Automake support is wanted for
>> > automatically defining foo_CFLAGS and foo_LDFLAGS. Any
>> > suggestion about what mechanism should be
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> * Ben Pfaff wrote on Mon, Feb 26, 2007 at 05:41:15AM CET:
>>
>> The issue is foo_CFLAGS and foo_LDFLAGS need to refer back to the
>> directory in which foo is installed. Thus, if foo is in
>> bin_PROGR
o complaints so far.
--
Ben Pfaff
[EMAIL PROTECTED]
http://benpfaff.org
Bruno Haible <[EMAIL PROTECTED]> writes:
> For reference, here are the changes that I did, compared to your patch.
Looks good.
> There is still one problem: The comment at the head of gl_RELOCATABLE
> says that it accepts an argument. But the macro uses always $gl_source_base,
> not $1.
Oops.
xx are used.
Typo: "might not work not" => "might not work on"
--
Ben Pfaff
[EMAIL PROTECTED]
http://benpfaff.org
Bruno Haible <[EMAIL PROTECTED]> writes:
> I think it's useful to separate the object files that end up in a relocatable
> program from the object files that make up the relocatable wrapper (on
> non-glibc systems). Reasons:
[...]
> For this reason, AC_LIBOBJ should be avoided here. This implies t
Bruno Haible <[EMAIL PROTECTED]> writes:
> If we recommend to use
>
> ./configure --enable-relocatable --prefix=/etc
> make
> make install DESTDIR=/tmp/inst$$
>
> then there should not be a security problem any more, right?
I tend to just use --prefix=$HOME/inst$$.
--
"While the Meli
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> * Ben Pfaff wrote on Sun, Mar 04, 2007 at 09:29:53PM CET:
>> Bruno Haible <[EMAIL PROTECTED]> writes:
>>
>> > If we recommend to use
>> >
>> > ./configure --enable-relocatable --prefix=/etc
Ben Pfaff <[EMAIL PROTECTED]> writes:
> I tend to just use --prefix=$HOME/inst$$.
and then later:
> Here's some suggested wording then:
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> I strongly recommend you use /nonexistent instead of $HOME. If $HOME
> is behind
Bruno Haible <[EMAIL PROTECTED]> writes:
> Paul Eggert wrote:
>> > extern long double acosl (long double x);
>>
>> In proofreading this I noticed that gnulib math.h isn't 100%
>> compatible with C99 math.h, since it doesn't allow you to include
>> math.h after a perverse macro definition like "
Bruno Haible <[EMAIL PROTECTED]> writes:
>> any future modules that I contribute (I have a few in mind)
>
> Of course I'd like to hear details :-) (when you have time for it).
The one that comes to mind immediately is to finish up and check
in the module for the "trunc" and "round" families of fu
Bruno Haible <[EMAIL PROTECTED]> writes:
> GNOME and some other GNU projects use the name 'autogen.sh' for scripts with
> this purpose. It's a well-known and self-explaining name. I'd suggest to
> rename 'bootstrap' to 'autogen.sh'.
One oddity of the name "autogen.sh" is that there is a GNU
proje
Ben Pfaff <[EMAIL PROTECTED]> writes:
> I tend to just use --prefix=$HOME/inst$$.
and then later:
> Here's some suggested wording then:
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> I strongly recommend you use /nonexistent instead of $HOME. If $HOME
> is behind
Thien-Thi Nguyen <[EMAIL PROTECTED]> writes:
> ChangeLog entry:
>
> * doc/gnulib.texi (Out of memory handling): Fix typos.
Thanks, I committed those typo fixes.
--
"Sanity is not statistical."
--George Orwell
Eric Blake <[EMAIL PROTECTED]> writes:
> According to Bruno Haible on 3/25/2007 9:57 AM:
>> Eric Blake wrote:
>>> /* return true iff the representation of d needs a leading '-' */
>>> bool
>>> is_negative (long double d)
>>> {
>>> if (d == 0)
>>> {
>>> union {
>>> long double d
Bruno Haible <[EMAIL PROTECTED]> writes:
> The code needed for isnan() needs to construct a NaN or Inf object. But
> doing so leads to a SIGFPE by default on Alpha systems. There's only one
> way to get IEEE compliant behaviour of elementary arithmetic operations on
> this platform: instruct the c
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
> So it seems that using fflush(stdin) is probably the wrong thing
> to do altogether for a portable application.
ISO C89 and C99 say that fflush(stdin) yields undefined behavior,
so I'm inclined to agree.
--
Ben Pfaff
[EMAIL PROTECTED]
Paul Eggert <[EMAIL PROTECTED]> writes:
> Ben Pfaff <[EMAIL PROTECTED]> writes:
>
>> ISO C89 and C99 say that fflush(stdin) yields undefined behavior,
>> so I'm inclined to agree.
>
> Here's how I remember it; I haven't checked the actual
Bruno Haible <[EMAIL PROTECTED]> writes:
> What do you gain by knowing this at configure time, rather than at "make"
> time, a little later? To proceed with the build, you need to install gperf
> anyway.
In PSPP, we've been trying to display all the missing
prerequisite libraries together at the
nv_open-aix.h iconv_open-hpux.h iconv_open-irix.h
iconv_open-osf.h
MOSTLYCLEANFILES += iconv_open-aix.h-t iconv_open-hpux.h-t
iconv_open-irix.h-t iconv_open-osf.h-t
--
Ben Pfaff
[EMAIL PROTECTED]
Ben Pfaff <[EMAIL PROTECTED]> writes:
> Building a program that imports iconv_open with builddir !=
> srcdir fails due to lack of $(srcdir) in the Makefile fragment.
>
> OK to commit the following?
Oops--the $(srcdir)/ is not necessary in the prerequisites, of
course.
--
"
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ben Pfaff wrote:
>> In PSPP, we've been trying to display all the missing
>> prerequisite libraries together at the end of a single configure
>> run, instead of just failing the configure run after finding the
>> f
1 - 100 of 462 matches
Mail list logo
