Re: socklen_t
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 other compilers do (as they are entitled to). For what it's worth, recent GCC has a warning option for this: `-Wendif-labels' Warn whenever an `#else' or an `#endif' are followed by text. This usually happens in code of the form #if FOO ... #else FOO ... #endif FOO The second and third `FOO' should be in comments, but often are not in older programs. This warning is on by default. -- "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." --Daniel Pead ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: Separate csharpcomp.sh, and a license problem
Bruno Haible <[EMAIL PROTECTED]> writes: > I agree with all this. I've changed gnulib-tool to accept modules whose > license is "GPLed build tool", and created a csharpcomp-script and > javacomp-script module under this license. This should make it clear > that - unlike the automake-provided build tools but exactly like > texinfo.tex - the tool is GPL but its use as build tool does not > infect your source with GPL. I'd expect that the purpose of a module (e.g. as code to compile and link or as a build tool) is orthogonal to its license. One could 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 mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: ULONG_MAX on Solaris
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 by each ruling group against its own subjects, and the object of the war is not to make or prevent conquests of territory, but to keep the structure of society intact." --George Orwell, _1984_ ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: gnulib-tool --lgpl exception for self tests?
Simon Josefsson <[EMAIL PROTECTED]> writes: > 2006-01-09 Simon Josefsson <[EMAIL PROTECTED]> > > * modules/gc-rijndael-tests (License): Likewise. > > * modules/gc-des-tests (License): Likewise. [...] > * modules/md2-tests (License): Likewise. I'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
Re: stdint_.h vs intmax_t & uintmax_t
"Mark D. Baushke" <[EMAIL PROTECTED]> writes:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> Mark D. Baushke wrote on 2005-11-15:
>> > it would be more portable to use this:
>> >
>> > #ifndef SIZE_MAX
>> > # define SIZE_MAX ((size_t)-1)
>> > #endif
>> >
>> > because ((size_t)-1) will work even if size_t is narrower than int.
>>
>> Yes. As explained on 2005-07-11, I prefer to write this as
>> ((size_t)~(size_t)0)
>> because this way we don't need to refer to ISO C 99 6.3.1.3.(2).
>
> Hmmm... let me see.
>
> ISO C 99 6.3.1.3.(2) says:
> | 2 Otherwise, if the new type is unsigned, the
> | value is converted by repeatedly adding or
> | subtracting one more than the maximum value that
> | can be represented in the new type until the
> | value is in the range of the new type. 49)
> |
> | 49) The rules describe arithmetic on the
> | mathematical value, not the value of a given
> | type of expression.
>
> I guess I didn't see the ISO C 99 reference in the
> 2005-07-11 posting. Perhaps, I didn't find the one
> you referenced...
I don't understand why ((size_t)-1) is considered C99 specific.
Here is the equivalent paragraph from C90, numbered 3.2.1.2.(2)
and .(3):
When a signed integer is converted to an unsigned integer
with equal or greater size, if the value of the signed
integer is nonnegative, its value is unchanged. Otherwise:
if the unsigned integer has greater size, the signed integer
is first promoted to the signed integer corresponding to the
unsigned integer; the value is converted to unsigned by
adding to it one greater than the largest number that can be
represented in the unsigned integer type. /22/
When an integer is demoted to an unsigned integer with
smaller size, the result is the nonnegative remainder on
division by the number one greater than the largest unsigned
number 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 integer has
greater size.
Thus, ((size_t)-1) is also the maximum value of size_t in C90.
Am I misunderstanding some argument here?
--
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
Re: gnulib-tool basics
[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 setup to pass the gnulib-tool settings as command-line options. -- "Let others praise ancient times; I am glad I was born in these." --Ovid (43 BC-18 AD) ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
intprops.h as a module?
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://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: removing asctime_r, ctime_r from the time_r module
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 this will happen. So > GNU apps shouldn't use these functions, and I propose that we remove > these function emulations from gnulib, as follows. Any objections? It would be nice to invent safe replacements, e.g. nasctime(), xasctime(). But I can understand that these functions might not be important enough to bother. -- "But hey, the fact that I have better taste than anybody else in the universe is just something I have to live with. It's not easy being me." --Linus Torvalds ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: fwriteerror() interface
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 stream if an error was reported > on the stream. Also, the test case provided does not make any > explicit call to fclose(), seeming to believe that fwriteerror() > always closes the stream. I still think this is a bug, but no one ever replied and no fix has been checked into CVS. Can anyone else confirm or deny that this is in fact a bug? -- 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
linebreak.h should include localcharset.h?
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 list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] fwriteerror() interface
Paul Eggert <[EMAIL PROTECTED]> writes: > In the latest patch, those three gotos confused me. Part of the > confusion is due to uses like 'if (fflush (fp))' which are of course > valid but which I find a bit hard to read at first. Also, the > comment's "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
badly sorted #include directives
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_H #include "c-ctype.h" #include "c-strtod.h" #include "error.h" [...] Of course, it's harmless, but it looks funny. I don't know whether the problem is in gnulib-tool or the modules that are sticking conditional inclusion directives in the list of headers. -- "I knew it was a bad sign when I drove through Hell (MI) on Wednesday and there was snow on the ground and all the standing water had a layer of ice on the surface... Yes folks, Hell has frozen over and my cable modem *still* wasn't working..." --Ed Glowacki
va_copy in gnulib?
Has anyone considered an emulation for missing va_copy() in gnulib? I notice that version-etc.c does this inline. It seems that it could be done pretty easily, either by wrapping or just creating a va_copy.h that's basically this: #include #ifndef va_copy #ifdef __va_copy #define 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
Re: Cygwin && WIN32
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 be neutral. How about W32_NATIVE then? I believe that some other GNU code uses w32 as a "32-bit Windows" prefix. -- "In this world that Hugh Heffner had made, he alone seemed forever bunnyless." --John D. MacDonald
Re: function portability documentation
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
> + On Windows systems, @code{wchar_t} is a 16-bit type and therefore cannot
> + accomodate all Unicode characters.
"accommodate"
> + @item chown
> + When applied to a symbolic link, some implementations don't dereference
> + the symlink, i.e. they behave like @code{lchown}.
i.e.@:
> + @item dirname
> + @code{dirname} assumes file names in POSIX syntax; it does not with file
> + names in Windows syntax.
"...does not" work "with file..."
> + @item fgetwc
> + @itemx fgetws
> + On Windows systems, @code{wchar_t} is a 16-bit type and therefore cannot
> + accomodate all Unicode characters.
"accommodate"
> + @item fopen
> + On Windows systems (excluding Cygwin), this function does not set
> @code{errno}
> + upon failure.
> +
> + On Windows, this function returns a file stream in "text" mode by default;
> + this means that it translates '\n' to CR/LF by default. Use the "b" flag
> + if you need reliable binary I/O.
"text" => ``text''
Should "b" be @samp{b}?
> + @item fprintf
> + On NetBSD and Windows, this function doesn't support format directives that
> + access arguments in an arbitrary order, such as "%2$s". The fix is to
> include
> + @file{} from GNU gettext; it redefines this function so that it
> is
> + POSIX compliant.
> +
> + On Windows, this function doesn't support the @code{'} flag and the
> @code{hh},
> + @code{ll}, @code{j}, @code{t}, @code{z} size specifiers.
The Texinfo manual says @samp{} should be used for single
characters, for what it's worth. Dunno if you care.
> + @item fputwc
> + @itemx fputws
> + On Windows systems, @code{wchar_t} is a 16-bit type and therefore cannot
> + accomodate all Unicode characters.
"accommodate"
Several other misspellings of this same word that I won't point
out separately.
> + @item getopt
> + The glibc implementation of @code{getopt} by default allows mixing option
> and
> + non-option arguments on the command line in any order. Other
> implementations,
> + such as the one in Cygwin, enfore strict POSIX compliance: they require that
> + the option arguments precede the non-option arguments. This is something to
> + watch out in your program's testsuite.
enfore => enforce
Is "testsuite" one word?
> + @item getpeername
> + Some systems don't have a @code{socklen_t} type; in this case this
> function's
> + third argument type is @samp{int *}.
Gnulib has a socklen module that should perhaps be mentioned here
(and in other references to socklen_t).
> + @item getsockopt
> + Some systems don't have a @code{socklen_t} type; in this case this
> function's
> + fifth argument type is @samp{int *}.
> +
> + Many socket options are not available on all systems.
Is it worth listing which socket options are specified in
the Unix standards, or can even those not be depended upon?
> + @item iconv
> + This function was not correctly implemented in glibc versions before 2.2.
> +
> + When @code{iconv} encounters an input character that is valid but that can
> + not be converted to the output character set, glibc's and GNU libiconv's
> + @code{iconv} stop the conversion. Some other implementations put an
> + implementation-defined character in the output buffer.
"can not" => "cannot"
> + @item iconv_open
> + The set of supported encodings and conversions is system dependent.
> +
> + @item index
> + This function is marked as ``legacy'' in POSIX. Better use @code{strchr}
> + instead.
> +
> + @item inet_addr
> + On some old systems, this function returns a @samp{struct in_addr} rather
> + than a scalar type such as @samp{unsigned int} or @samp{unsigned long}.
> +
> + @item ioctl
> + Most @code{ioctl} requests are platform and hardware specific.
> +
> + @item isatty
> + On Windows, @code{isatty} also returns true for character devices such as
> + "NUL".
Should "NUL" be @file{NUL}?
> + @item mkdir
> + When the argument ends in a slash, the function call fails on some systems.
> +
> + On Windows systems (excluding Cygwin), this function is called @code{_mkdir}
> + and takes only one argument. The fix is to define a macro like this:
> + @smallexample
> + #define mkdir ((int (*)()) _mkdir)
> + @end smallexample
Is that better than this?
#define mkdir(a,b,c) _mkdir(a,b)
> + @item mktime
> + Some implementations of @code{mktime} may go into an endless loop.
Ouch. Is there a workaround?
> + @item nanosleep
This entry is empty.
> + @item open
> + On Windows, this function returns a file handle in @code{O_TEXT} mode by
> + default; this means that it translates '\n' to CR/LF by default. Use the
> + @code{O_BINARY} flag if you need reliable binary I/O.
It seems slightly odd to mix C and character name notation.
Perhaps "translates '\n' to
SSIZE_MAX
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 files in lib/ already include something like this. -- "If a person keeps faithfully busy each hour of the working day, he can count on waking up some morning to find himself one of the competent ones of his generation." --William James
Re: SSIZE_MAX
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.h. Or they could be combined into one header file. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org
Re: SSIZE_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 > headers on different systems. Is that also true for SSIZE_MAX? > > I don't offhand recall SSIZE_MAX being defined anywhere other than its > standard location . If so, then we wouldn't need a > ssize_max.h header, and we wouldn't need to overload size_max.h; we > could just tell people to include . The ssize_t module is there, I think, because ssize_t isn't necessarily defined at all on all systems. ssize_t.m4 defines it as "int" on systems that don't have it: if test $gt_cv_ssize_t = no; then AC_DEFINE(ssize_t, int, [Define as a signed type of the same size as size_t.]) fi If ssize_t doesn't exist then I wouldn't expect SSIZE_MAX to exist either. The current ssize_t module doesn't define SSIZE_MAX, but, in my opinion, it should. That's really what I'm trying to suggest, although I suppose suggesting a mechanism instead of describing the actual goal is confusing. -- "Then, I came to my senses, and slunk away, hoping no one overheard my thinking." --Steve McAndrewSmith in the Monastery
Re: result type of INT16_C, UINT16_C
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_least16_t or > uint_least16_t. How can INT16_C, UINT16_C be defined then? I think you are overlooking the changes in Technical Corrigendum 1, which includes the following: 33. Page 259, 7.18.4 Add a new paragraph 3: [#3] Each invocation of one of these macros shall expand to an integer constant expression suitable for use in #if preprocessing directives. The type of the expression shall have the same type as would an expression of the corresponding type converted according to the integer promotions. The value of the expression shall be that of the argument. 34. Page 259, 7.18.4.1 Remove the first paragraph and footnote 221. 35. Page 259, 7.18.4.1 Change to existing paragraph 2, also renumbering it as 1: [#1] The macro INTN_C(value) shall expand to an integer constant expression corresponding to the type int_leastN_t. The macro UINTN_C(value) shall expand to an integer constant expression corresponding to the type uint_leastN_t. For example, if uint_least64_t is a name for the type unsigned long long int, then UINT64_C(0x123) might expand to the integer constant 0x123ULL. 36. Page 260, 7.18.4.2 In paragraph 1, change both occurrences of "integer constant" to "integer constant expression". -- "If a person keeps faithfully busy each hour of the working day, he can count on waking up some morning to find himself one of the competent ones of his generation." --William James
Re: Portablity bug in base64.c
[EMAIL PROTECTED] (Larry Jones) writes: > Some older preprocessors substitue macro parameter names that occur in > character constants or string literals. This breaks base64.c since it > uses x as a parameter name in a macro that has a 'x' character constant > in its expansion. 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
Re: [bug-gnulib] Re: result type of INT16_C, UINT16_C
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 _so_ enjoy making a fool out of myself." --Linus, on Christmas Day, 2000
Re: proposed simplification rewrite of stdint module
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 have avoided most > (though not all) of the porting problems we've had recently. I don't know whether it really matters in practice, but C99 says that these types are typedefs, not macros. -- "Long noun chains don't automatically imply security." --Bruce Schneier
Re: new module for temporary files in temporary directories
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 message >is shown and NULL is returned. */ > extern struct temp_dir * create_temp_dir (const char *prefix); I find the description just a little confusing: PREFIX is a prefix for the *base name* of the temporary directory. It actually goes in the middle of the directory name. I like the concept otherwise. I can probably drop some code from GNU PSPP if this is installed. (PSPP also uses temporary files for sorting.) -- "Implementation details are beyond the scope of the Java virtual machine specification. One should not assume that every virtual machine implementation contains a giant squid." --"Mr. Bunny's Big Cup o' Java"
Re: new module for temporary files in temporary directories
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);
>
> I would like a barrier to ensure that all memory stores of
> set_up_datastructures() have been performed before the signal handler
> is activated. __asm__("" : : : "memory"); is not portable (works only with
> GCC). Calls to an empty global function are optimized away by GCC 4. [...]
Is it safe to use an external function that is only defined in a
separate translation unit? For example, to define an empty
function in a source file all by itself, then use a call to it as
a barrier. This introduces a barrier in the common situations
that I know about, although there is the small overhead of a
call-and-return sequence. (Are there compilers or linkers that
do inter-module optimization?)
--
"Term, holidays, term, holidays, till we leave school,
and then work, work, work till we die."
C. S. Lewis
Re: new module for temporary files in temporary directories
Paul Eggert <[EMAIL PROTECTED]> writes: > Bruno Haible <[EMAIL PROTECTED]> writes: > >> 3) The theoretical reason is that in ISO C, section 5.1.2.3.(5) >> guarantees to me that memory stores have been performed at sequence points >> only if I mark them 'volatile'. > > I think that's a misunderstanding of that section. > > From the C standard's point of view, a volatile object (not merely an > object accessed via a volatile lvalue, but a volatile object, e.g., > "static int volatile x;") has externally visible behavior. You can > think of such objects as having little oscilloscope probes attached to > them, so that the user can observe every access to them, just as the > user can observe data written to output files. This is not true of > ordinary objects accessed via volatile lvalues (which is what the new > module mostly uses); only volatile objects can be observed by the > user. > > 5.1.2.3.(5) talks only about volatile objects; it does not place any > constraints on accesses to ordinary objects via volatile lvalues. This is a particularly pessimistic interpretation of the standard, and I do not agree with it. The standard is careful to distinguish between objects of a type and objects *defined* with a particular type. An object having a type is just ascribing a relatively arbitrary type to a memory region, as you can see from the relevant definitions in C99: 3.14 1object region of data storage in the execution environment, the contents of which can represent values 2NOTE When referenced, an object may be interpreted as having a particular type; see 6.3.2.1. ... 6.3.2 Other operands 6.3.2.1 Lvalues, arrays, and function designators 1An lvalue is an expression with an object type or an incomplete type other than void;53) if an lvalue does not designate an object when it is evaluated, the behavior is undefined. When an object is said to have a particular type, the type is specified by the lvalue used to designate the object. Note in particular the final sentence above: the type used for an object is a function of the lvalue. An object *defined* as a type means that there is a declaration that says it has the type, as in your "static int volatile x;" example. The standard carefully distinguishes these forms of reference. For example, 6.7.3p5 talks about the *defined* type of an object: If an attempt is made to refer to an object defined with a volatile-qualified type through use of an lvalue with ^^^ non-volatile-qualified type, the behavior is undefined.113) But 5.1.2.3p5 talks about the type of an object, with no reference to how the object was defined: The least requirements on a conforming implementation are: - At sequence points, volatile objects are stable in the sense that previous accesses are complete and subsequent accesses have not yet occurred. The C99 rationale makes this clear, in 6.7.3p10, although the wording is looser (I do not think that the rationale receives 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
Re: new module for temporary files in temporary directories
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. Here's a sample quote (in the threading area):
>
> ... the use of volatile accomplishes nothing but to prevent the
> compiler from making useful and desirable optimizations, providing
> no help whatsoever in making code "thread safe".
>
> Dave Butenhof, comp.programming.threads (1997-07-03)
>
> <http://groups.google.com/group/comp.programming.threads/msg/bd2cb64e70c9d155>
I do not think that signal handlers are perfectly analogous to
threads, although I will not deny that as both are examples of
asynchronous behavior, they are certainly related.
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 returning from the
signal handler. This is much simpler than the general problem of
synchronizing many threads. It is a little like a single thread
that runs for a while, then switches to another thread a single
time, and then both threads terminate.
>> 5.1.2.3p5 talks about the type of an object, with no
>> reference to how the object was defined:
>>
>> The least requirements on a conforming implementation are:
>>
>> - At sequence points, volatile objects are stable in the
>>
>>sense that previous accesses are complete and subsequent
>>accesses have not yet occurred.
>
> As I understand it, under your interpretation this signal handler:
>
>#include
>#include
>sig_atomic_t x;
>void handler (int sig) { sig_atomic_t volatile *p = &x; *p = 0; }
>
>int main (void)
>{
> signal (SIGINT, handler);
> x = 1;
> getchar ();
> return x;
>}
>
> always has well-defined behavior, since the signal handler simply
> stores 0 into a sig_atomic_t volatile object and it's immaterial how
> the object was defined. So if a signal arrives during the call to
> getchar, then 'main' must return 0 and not 1.
>
> But this interpretation doesn't correspond to how compilers behave.
> If the type sig_atomic_t is plain 'int', for example, a compiler is
> entitled to cache other references to x's contents even in the
> presence of signals. Both GCC and Sun C do this, e.g., on 64-bit
> SPARC they don't bother to set 'x' before getchar returns. More
> generally, I don't see how an object can be both volatile and
> nonvolatile at the same time: it has to be one or the other. Yet
> lvalues of both kinds can exist simultaneously.
I won't make a claim that the signal handler in the above code is
guaranteed to see 1 if called during getchar, because the
assignment in main does not access a volatile object.
However, I believe that if the assignment in main were changed to
the following, then the signal handler would be guaranteed to see
1 in x if the signal arrived in getchar;
*(sig_atomic_t volatile *) &x = 1;
To me, this is exactly what the C99 rationale is saying in 6.7.3,
toward the end:
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.
With the cast, `x' is accessed as a volatile object, because it
is accessed through a volatile lvalue. This is consistent with
the definitions of "object" and "lvalue" in the standard (and that
is why I quoted their definitions earlier).
> I suspect that I am simply misunderstanding your argument (which is
> not uncommon in this area!). If so, then if you could flesh out the
> argument a bit, that might help. (But I should warn you that I've
> never yet understood "volatile", despite my asking some very bright
> people what it actually means. :-)
I am not confident that I understand volatile correctly, either,
but I do want to help. I hope that my comments can clarify,
rather than throw additional mud on already muddy ground.
Maybe I am not being helpful because I misunderstood your
original objection. Perhaps all this is moot because Bruno's
module does not actually contain any casts to volatile.
> PS. MacLaren proposed a change to the C standard which would in his
> opinion fix some (but not all) of the problems with respect to signal
> handling and volatile; see
> <http://www.davros.org/c/public/pcuk0097.txt>.
> However, this proposal was not accepted.
I was aware that there had been a proposal, but not of the
details. Thanks for the pointer (and for the Open Group version
too).
--
"But hey, the fact that I have better taste than anybody else in the
universe is just something I have to live with. It's not easy being
me."
--Linus Torvalds
Re: new module for temporary files in temporary directories
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 returning from the >> signal handler. This is much simpler than the general problem > > Yes, good point; it is simpler. However, my impression is that the > new module's cleanup function is intended to be callable even from > non-fatal signal handlers, so I don't think we have the simpler case > here. But for now let's concentrate on the simpler case. Is this a feature that Bruno will add later? I don't see a way to do it at the moment. >> However, I believe that if the assignment in main were changed to >> the following, then the signal handler would be guaranteed to see >> 1 in x if the signal arrived in getchar; >> *(sig_atomic_t volatile *) &x = 1; > > OK, so it sounds like your idea is that, if all accesses to an object > are via a volatile lvalue, then the object is volatile, even if it was > not originally defined to be a volatile object. This idea has an > intuitive appeal, though I submit that it does not follow from the > standard; the standard does not explicitly specify or even suggest > this "all accesses" rule. I think I'm still not doing a good job of explanation. My theory is that any object may be accessed through a volatile lvalue and receive volatile semantics *for that access* (rationale 6.7.3, last paragraph). An object *defined as* volatile must always be accessed through a volatile lvalue (6.7.3p5). But an object *not* defined as volatile *may* be accessed through a volatile lvalue (6.7.3p7). That doesn't make the object volatile and it doesn't mean that you always have to access the object via volatile semantics. > A problem I see with this idea is 6.7.3.(6), which says "An object > that has volatile-qualified type may be modified in ways unknown to > the implementation or have other unknown side effects." So a volatile > object (I assume this is the same as "an object that has > volatile-qualified type" in your model?) can spontaneously change, for > reasons unknown to and outside the control of the program; this point > is underlined later in the paragraph. But if all accesses to a > humdrum "static int x;" object are via volatile lvalues, and if that > means "x" is a volatile object, doesn't this also mean "x" might > spontaneously change? I have always "read between the lines" that this applies only to volatile objects that actually refer to unusual things that are not normal memory (e.g. MMIO, as you say), probably involving linker scripting or pointer casts to assign them to magical addresses. It has never occurred to me that it applies to every volatile object. For example, consider the use of "volatile" in conjunction with "longjmp", to guarantee that automatic variables have unsurprising values after the jump. It would be *very* surprising if these values spontaneously changed! > One way out of this mess would be to say that we are making an extra > assumption, not present in the standard, that volatile objects do not > spontaneously change and that they have no unknown side effects. To > some extent we must make this assumption anyway, or we'll get nowhere. > Still, 6.7.3.(6) makes it clear (at least to me) that "volatile" is > intended more for describing access to memory-mapped device registers, > and wasn't really intended for use in safe signal handling or > multithreading. Yes. > There is also the huge escape clause at the end of 6.7.3.(6): "What > constitutes an access to an object that has volatile-qualified type is > implementation-defined." Ouch! Talk about getting run over by an > express train! No kidding. > Anyway, to get back to the original module, it seems to me that the > code actually is assuming something quite a bit different from what > 'volatile' provides. The code is attempting to do use loads and > stores as barriers to prevent the usual sorts of bugs with signal > handling. But 'volatile' is not designed to handle this problem: > volatile accesses are not guaranteed to be atomic. It'd be *much* better if we had a way to do atomic accesses--please don't take my arguments as being *in favor of* volatile. Almost any other solution would be preferable. It's too bad that all the other solutions are even less portable (as far as I know). -- "Ho ho ho. I _so_ enjoy making a fool out of myself." --Linus, on Christmas Day, 2000
Re: split stdio-safer into fopen-safer, tmpfile-safer
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 email: [EMAIL PROTECTED] web: http://benpfaff.org
Re: split stdio-safer into fopen-safer, tmpfile-safer
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 allowed to leave a permanent > file behind if the call to tmpfile() is interrupted, or if the > process _exit()s. Yet there is no way to know what that file > is. At least with mkstemp, you choose the file prefix. Even > though there is a race between the time that you mkstemp() and > unlink(), such that the same problem exists of leaving a > permanent file behind if interrupted at the wrong time, at > least you can document to the user where to look for bogus > files. Another reason is that POSIX allows implementations to > limit you to TMP_MAX tmpfiles, which may be smaller than the > number of open fd's allowed. (Hmm - sounds like an aardvark is > in order, since POSIX still calls out TMP_MAX in the normative > text to tmpnam, but deleted it from limits.h). OK. Those issues are reasonable. I was worried that there was something bigger here. Usually a "safety" issue is something more important than leaving a temporary file undeleted or limiting their number, like the possibility of a security hole, a segfault, etc. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org
Re: typo in error module
Eric Blake <[EMAIL PROTECTED]> writes: > On glibc platforms, error_at_line currently violates GNU coding standards > when > the output stream is in wide character mode. OK to apply? Does this need to > be pushed to glibc? Is it useful if it isn't pushed to glibc? It only updates code inside an #ifdef _LIBC block. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org
Re: new module proposal: verror
Eric Blake <[EMAIL PROTECTED]> writes:
> +void
> +verror (int status, int errnum, const char *format, va_list args)
> +{
> + char *message = xvasprintf (format, args);
> + error (status, errnum, message);
Surely that should be
error (status, errnum, "%s", message);
and similarly for verror_at_line?
> + free (message);
> +}
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
Re: new module c-strstr
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 contiguous: In both the source and execution basic character sets, the value of each character after 0 in the above list of decimal digits shall be one greater than the value of the previous. -- "Then, I came to my senses, and slunk away, hoping no one overheard my thinking." --Steve McAndrewSmith in the Monastery
portability of 64-bit types?
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 support 64-bit integers under the name "long long", so I'm planning to use gnulib's stdint.h, which already has the necessary incantations, and access the type as uint_least64_t. -- Peter Seebach on managing engineers: "It's like herding cats, only most of the engineers are already sick of laser pointers."
Re: printing size_t variables
"Mark D. Baushke" <[EMAIL PROTECTED]> writes: [printf] > I would not mind seeing both the j and z modifiers > generally implemented. However, as Bruno mentions, > this would likely be a fair amount of overhead just > for those few format characters. I think casting 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). -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org
Re: new module proposal: split
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
Re: new module proposal: split
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 is: >> > char *split(const char *str, char sep, int *argc); >> > >> > what do you think about? >> >> What does it do? > split() splits the string "str" into an array of strings accordingly "sep" > and returns that array and it's size in *argc. The array is allocated via > malloc(). When SEP characters are adjacent, does split output an empty string? That is, does it follow strsep or strtok semantics for adjacent delimiters? -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org
Re: proper names
Bruno Haible <[EMAIL PROTECTED]> writes: > OK to add this module to gnulib? I like the module. But I think that the background and usage that you included in your message should be checked in also, so that it's clear. I would not, for example, immediately think to update the XGETTEXT_OPTIONS variable, but your message tells me to do so and gives the right syntax. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org
Re: setlocale
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
Re: gettext.h patch for portability to sunCC, pgCC, RHEL AS 4 g++
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 shows the expression in an array-declarator to be a constant-expression (see section 8.3.4). If a later version of ISO C++ does support variable-size arrays--I don't have any later version of the standard--then why not test that __cplusplus is at least that version? -- "The road to hell is paved with convenient shortcuts." --Peter da Silva
Re: yet another hello pretest
Eric Blake <[EMAIL PROTECTED]> writes: > + /* Even exiting has subtleties. The /dev/full device on GNU/Linux > + can be used for testing whether writes are checked properly. For > + instance, hello >/dev/null should exit unsuccessfully. On exit, s%dev/null%dev/full% > + 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
Re: yet another hello pretest
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 you have > EXIT_*, using EXIT_* in general? > > I'm less sure about EXIT_SUCCESS, but could give reasons why both of > the others are A Good Idea. EXIT_SUCCESS is in C89. -- "Ho ho ho. I _so_ enjoy making a fool out of myself." --Linus, on Christmas Day, 2000
Re: coreutils 6.6 HP-UX build error
Paul Eggert <[EMAIL PROTECTED]> writes: > Come to think of it, since we want the code to stay portable to C89, > then we can't use switch (V) ... when V is of type off_t. This is > because off_t is typically 'long long int', and C89 (which lacks 'long > long int') does not require support for a switch whose expression is > of type 'long long int'. I don't understand this rationale. C89 requires that the switch expression be of integral type. For C89 compilers with the long long int extension, a long long int is an 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
Re: Incompatibility between current gnulib and gettext-0.14.6?
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.61. So it's coming up soon for Debian unstable now... -- Peter Seebach on managing engineers: "It's like herding cats, only most of the engineers are already sick of laser pointers."
module for missing math.h functions?
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? I am particularly interested in those two functions, which are handy for GNU PSPP, and so I am likely to write such a module if acceptance would be likely. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org
Re: [bug-gnulib] module for missing math.h functions?
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 you write it so that it augments , > like we do for or ? That is my plan. > Can substitutes in gnulib assume that the 'double' format is IEEE 754 > (it is on all modern platforms; VAX was the last one with other formats) ? > Or should they be written in a slower, but more portable way? This question is actually vital. If we can assume IEEE 754, then I can use implementations from glibc. If we can't, then it is more difficult, and I will have to see how clever I can be. Do we have any opinions on this? -- "Implementation details are beyond the scope of the Java virtual machine specification. One should not assume that every virtual machine implementation contains a giant squid." --"Mr. Bunny's Big Cup o' Java"
tests/test-base64.c: executable?
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."
Re: module for missing math.h functions?
Paul Eggert <[EMAIL PROTECTED]> writes:
> For other math.h functions it's a vital question, but you should be
> able to implement trunc and round portably using ceil and floor, and
> this should work correctly even for IEEE 754 hosts. Something like
> this:
>
>double
>rpl_trunc (double x)
>{
> return x < 0 ? ceil (x) : 0 < x ? floor (x) : x;
>}
>[...]
You are cleverer than me. Thanks.
Here is my first stab at a module. I don't really know what I'm
doing--I just tried to look at modules that did similar things
for guidance, but it wasn't always clear to me which of several
choices to pick--so feedback is very much appreciated.
The following actually makes an unconditional wrapper around
, in the same way as the fcntl module does.
I used floorl and ceill from the mathl module to implement roundl
and truncl. I defined roundf and truncf to just call round and
trunc, but another option would be to implement floorf and ceilf
in the same way as roundl and truncl.
I haven't actually tested the function implementations. It does
pass "gnulib-tool --test math" for what it's worth, at least on
my GNU/Linux system.
Index: MODULES.html.sh
===
RCS file: /cvsroot/gnulib/gnulib/MODULES.html.sh,v
retrieving revision 1.161
diff -u -p -r1.161 MODULES.html.sh
--- MODULES.html.sh 20 Nov 2006 22:07:27 - 1.161
+++ MODULES.html.sh 28 Nov 2006 06:08:45 -
@@ -1832,6 +1832,7 @@ func_all_modules ()
func_echo "$element"
func_begin_table
+ func_module math
func_module mathl
func_end_table
Index: lib/math_.h
===
RCS file: lib/math_.h
diff -N lib/math_.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lib/math_.h 28 Nov 2006 06:08:45 -
@@ -0,0 +1,46 @@
+/* Provide a more complete set of math functions.
+ Copyright (C) 2006 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY 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, Boston, MA 02110-1301, USA. */
+
+/* Written by Ben Pfaff. */
+
+#ifndef _gl_MATH_H
+#define _gl_MATH_H
+
+#include @ABSOLUTE_MATH_H@
+#include "mathl.h"
+
+#if !HAVE_DECL_ROUNDF
+float roundf (float);
+#endif
+#if !HAVE_DECL_ROUND
+double round (double);
+#endif
+#if !HAVE_DECL_ROUNDL
+long double roundl (long double);
+#endif
+
+#if !HAVE_DECL_TRUNCF
+float truncf (float);
+#endif
+#if !HAVE_DECL_TRUNC
+double trunc (double);
+#endif
+#if !HAVE_DECL_TRUNCL
+long double truncl (long double);
+#endif
+
+#endif /* _gl_MATH_H */
Index: lib/round.c
===
RCS file: lib/round.c
diff -N lib/round.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lib/round.c 28 Nov 2006 06:08:45 -
@@ -0,0 +1,75 @@
+/* round.c - portable implementation of round functions.
+
+ Copyright (C) 2006 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY 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, Boston, MA 02110-1301, USA.
+
+ Written by Paul Eggert and Ben Pfaff. */
+
+#include
+
+#if !HAVE_ROUNDF
+float
+roundf (float x)
+{
+ return round (x);
+}
+#endif /* !HAVE_ROUND */
+
+#if !HAVE_ROUND
+double
+round (double x)
+{
+ if (x < 0)
+{
+ double t = ceil (x);
+ if (0.5 <= t - x)
+t--;
+ return t;
+}
+ else if (0 < x)
+{
+ double t = floor (x);
+ if (0.5 <= x - t)
+t++;
+ return t;
+}
+ else
+return x;
+}
+#endif /* !HAVE_ROUND */
+
+#if !HAVE_ROUNDL
+long double
+roundl (long double x)
+{
+ if (x < 0)
+{
+ long double t = ceill (x);
+ if (0.5 <= t - x)
Re: stdint problem
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 realized that when I started packaging Autoconf snapshots for Debian. I'm not sure that I'll continue to do so in the future, at least outside of Debian's "experimental" section, because it seems to cause actual problems for people in practice. -- "Welcome to the Slippery Slope. Here is your handbasket. Say, can you work 70 hours this week?" --Ron Mansolino
Re: gnulib broken on systems lacking fchdir
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 code either, so that there are less > differences between the code and user documentation. But 'filename' and > 'file' are fine according to everyone. The standards.info I have here says that "file name" should be two words, not one: Please do not use the term "pathname" that is used in Unix documentation; use "file name" (two words) instead. We use the term "path" only for search paths, which are lists of directory names. -- "MONO - Monochrome Emulation This field is used to store your favorite bit." --FreeVGA Attribute Controller Reference
why don't Gnulib tests run for me?
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 when I use "gnulib-tool --test ", the tests for the module don't actually seem to run. This seems to be because the Makefile.am module specification is not getting propagated to any actual Makefile.am. For example, for me, when I run the following: ./gnulib-tool --create-testdir --dir=foo arcfour-tests grep -r TESTS foo I get null output, even though the arcfour-tests module contains the following: Makefile.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
Re: why don't Gnulib tests run for me?
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 when I use "gnulib-tool --test ", the >> tests for the module don't actually seem to run. > > I think you also want --with-tests. That did it. Thanks! -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org
Re: test modules and license
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ralf Wildenhues wrote:
>> > + @quotation
>> > + Copyright @copyright{} 2002-2007 Free Software Foundation, [EMAIL
>> > PROTECTED]
>>
>> The minimum copyright year surely would have to be adjusted.
>
> For the documentation purpose here, I think this is not relevant. But you
> can also write 200X-200Y if you prefer that.
The maintainers' guide says not to use a range at all:
Do not abbreviate the year list using a range; for instance, do not
write `1996--1998'; instead, 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 systematically change the notice in every
old file.
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
Re: gnu math library
[EMAIL PROTECTED] (Karl Berry) writes: > There is an ancient GNU package called variously "GNU Math" and "GNU > SSL" (no relation to the cryptographic ssl). The last release was in > 1996, at ftp://ftp.gnu.org/gnu/gnussl. It contains some routines > written in C++ for matrix operations and maybe other stuff, including > Fourier transforms, it seemed. > > Anyway, my question is, does anyone happen to know if the standard C++ > libraries, or maybe libmatheval (Aleksandar?) contain support for these > things? It seemed familiar to me even back from libg++ days, but I > don't know what the current status is. The GNU Scientific Library (GSL) has routines that do matrix operations, Fourier transforms (which you mention), numerical linear algebra, and that aid with some kinds of plotting (which are mentioned in the GNU SSL README). 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
memset.c needs #include ?
Most non-trivial .c files in gnulib's lib directory include config.h, but some do not. One that is causing problems for compiling GNU PSPP in some environments is memmem.c. This file includes gnulib's replacement , which uses restrict. If this is compiled on a system that lacks support for the C99 restrict keyword, on which config.h defines "restrict" out of existence, it fails because the compiler still sees the uses of restrict. I assume the memmem.c problem should be fixed just by including . Using "fgrep -L config.h lib/*.c" I see there are others that 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
wint_t in printf-args.c under mingw32
While compiling GNU PSPP under mingw32, for portability testing purposes, I noticed an error from printf-args.c in gnulib: ../../intl/printf-args.c: In function `printf_fetchargs': ../../intl/printf-args.c:83: warning: `wint_t' is promoted to `int' when passed through `...' ../../intl/printf-args.c:83: warning: (so you should pass `int' not `wint_t' to `va_arg') ../../intl/printf-args.c:83: note: if this code is reached, the program will abort which corresponds to these source lines: #ifdef HAVE_WINT_T case TYPE_WIDE_CHAR: ap->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
Re: wint_t in printf-args.c under mingw32
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
fix inadequate Windows implementation of tmpfile
Under Windows, the tmpfile function is defined to always create
its temporary file in the root directory. Most users don't have
permission to do that, so it will often fail. I'm proposing a
"tmpfile" module that detects this situation and replaces tmpfile
with a better implementation.
The implementation I provide is Windows-specific, because the
common Unix implementation of temporary files (open then
immediately unlink) doesn't work on Windows, which doesn't permit
deleting open files. I using the clean-temp module instead, as a
more portable solution, but then I needed to interpose upon
fclose (and perhaps close as well) to delete the temporary file
when it was closed, which quickly turned into a mess. Using the
Windows "delete on close" _O_TEMPORARY flag is a simpler
solution.
I've tested this solution on mingw/Wine and it works well there.
I haven't tested it on a real Windows machine because I don't
have easy access to one.
All feedback is appreciated.
Index: MODULES.html.sh
===
RCS file: /cvsroot/gnulib/gnulib/MODULES.html.sh,v
retrieving revision 1.194
diff -u -p -r1.194 MODULES.html.sh
--- MODULES.html.sh 15 Feb 2007 03:07:04 - 1.194
+++ MODULES.html.sh 15 Feb 2007 15:18:20 -
@@ -1539,6 +1539,16 @@ func_all_modules ()
func_module pagealign_alloc
func_end_table
+ element="Input/Output "
+ element=`printf "%s" "$element" | sed -e "$sed_lt" -e "$sed_gt"`
+ func_section_wrap ansic_enh_stdio
+ func_wrap H3
+ func_echo "$element"
+
+ func_begin_table
+ func_module tmpfile
+ func_end_table
+
element="Sorting functions "
element=`printf "%s" "$element" | sed -e "$sed_lt" -e "$sed_gt"`
func_section_wrap ansic_enh_stdlib_sorting
Index: lib/tmpfile.c
===
RCS file: lib/tmpfile.c
diff -N lib/tmpfile.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lib/tmpfile.c 15 Feb 2007 15:18:21 -
@@ -0,0 +1,89 @@
+/* Replacement for inadequate Windows implementation of tmpfile.
+ Copyright (C) 2007 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY 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, Boston, MA 02110-1301, USA. */
+
+/* Written by Ben Pfaff. */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pathmax.h"
+#include "xallocsa.h"
+#include "tempname.h"
+#include "tmpdir.h"
+
+#define WIN32_LEAN_AND_MEAN
+#include
+
+FILE *
+tmpfile (void)
+{
+ char *dir;
+ char *xtemplate;
+ DWORD retval;
+ size_t len;
+ int fd;
+ FILE *file = NULL;
+
+ dir = (char *) xallocsa (PATH_MAX);
+ xtemplate = (char *) xallocsa (PATH_MAX);
+
+ /* Find Windows temporary file directory.
+ We provide this as the directory argument to path_search
+ because Windows defines P_tmpdir to "\\" and will therefore
+ try to put all temporary files in the root (unless $TMPDIR
+ is set). */
+ retval = GetTempPath (PATH_MAX, dir);
+ if (retval == 0 || retval >= PATH_MAX - 1)
+goto done;
+
+ if (path_search (xtemplate, PATH_MAX, dir, NULL, true))
+goto done;
+ len = strlen (xtemplate);
+
+ do
+{
+ strcpy (&xtemplate[len - 6], "XX");
+ if (gen_tempname (xtemplate, GT_NOCREATE))
+goto done;
+
+ fd = _open (xtemplate,
+ _O_BINARY | _O_CREAT | _O_TEMPORARY | _O_EXCL | _O_RDWR,
+ _S_IREAD | _S_IWRITE);
+}
+ while (fd < 0 && errno == EEXIST);
+ if (fd < 0)
+goto done;
+
+ file = _fdopen (fd, "w+b");
+ if (file == NULL)
+{
+ int save_errno = errno;
+ _close (fd);
+ errno = save_errno;
+}
+
+ done:
+ freesa (xtemplate);
+ freesa (dir);
+ return file;
+}
Index: m4/tmpfile.m4
===
RCS file: m4/tmpfile.m4
diff -N m4/tmpfile.m4
--- /dev/null 1 Jan 1970 00:00:00 -
+++ m4/tmpfile.m4 15 Feb 2007 15:18:21 -
@@ -0,0 +1,39 @@
+# Check whether tmpfile will work for ordinary users who do not have
+# permissions to write in the root directory.
+
+#
Re: fix inadequate Windows implementation of tmpfile
Bruno Haible <[EMAIL PROTECTED]> writes: > So, to test whether native Woe32 API is available, use > > defined _WIN32 || defined __WIN32__ Ben Pfaff <[EMAIL PROTECTED]> writes: > + [[#ifdef __WIN32__ > +choke me > +#endif ]])], Oops. Thanks Bruno, I'll fix up that part of my patch. -- Ben Pfaff [EMAIL PROTECTED] http://benpfaff.org
Re: fix inadequate Windows implementation of tmpfile
Bruno Haible <[EMAIL PROTECTED]> writes: > Here, it's debatable whether the tmpfile() function in MSVCRT is broken: > On one hand, ISO C 99 says >"It should be possible to open at least TMP_MAX temporary files during > the lifetime of the program..." > which isn't fulfilled, as you say, if the user doesn't have the permissions. > (Btw, such situations can also occur on Unix! KDE becomes unusable when > /tmp is full.) > > On the other hand, Microsoft's doc of tmpfile > http://msdn2.microsoft.com/en-us/library/x8x7sakw(VS.80).aspx > and of tmpfile_s > http://msdn2.microsoft.com/en-us/library/b3dz6009(VS.80).aspx > explicitly says > "The temporary file is created in the root directory." > > So, your replacement doesn't fulfill the Microsoft doc. Therefore, I think > you should choose a different name for your function, since you want it > to behave differently than the documented behaviour of tmpfile() on Windows. I agree that the Windows implementation is, arguably, C99 and POSIX compliant. But I claim that it has an unreasonably poor quality of implementation, bad enough that we should replace it. If a Unix-like system implemented its tmpfile in a similar way, by always attempting to create a file in the root directory and failing if permissions were lacking, I imagine that we'd all accept that this is a poor implementation that should be replaced. To me the Microsoft documentation seems like a red herring. The way I've always thought about Gnulib is that it allows a GNU program to make assumptions about its environment that GNU programmers find comfortable, by covering up the differences where it is possible. For example, GNU programmers find it comfortable to assume that malloc(0) returns non-null, so Gnulib helps with that. > The _O_TEMPORARY flag is interesting. It appears to be portable to all > versions of Windows since Woe95. What can you say about its reliability? > The native tmpfile() uses this flag as well. Is a file created with tmpfile() > on Windows deleted when you interrupt the program with Ctrl-C / Ctrl-Break? I've only tested it under Wine, not under any version of Windows, so I can't really say for sure. There seems to be some kind of problem with FILE_FLAG_DELETE_ON_CLOSE, with which _O_TEMPORARY is presumably implemented, under Windows 95: http://cygwin.com/ml/cygwin-cvs/2003-q4/msg00025.html In fact, it appears that FILE_FLAG_DELETE_ON_CLOSE works on NT derivatives, not on the older Windows systems, based on the has_delete_on_close definitions here (sorry about citing a patch when a source file would probably be better, this is based on a very quick search): http://www.cygwin.com/ml/cygwin-patches/2003-q1/msg00170.html Where it works, it appears to be implemented such that it always works, even if a program is terminated abruptly, based on what I've read on the web. >> I using the clean-temp module instead, as a >> more portable solution, but then I needed to interpose upon >> fclose (and perhaps close as well) to delete the temporary file >> when it was closed, which quickly turned into a mess. > > Can 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
check for C99-compliant snprintf
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-compliant, it just checks for its presence. This is a problem with, e.g. Windows, which has such a noncompliant snprintf. The following patch attempts to remedy the situation. It works fine for me with mingw32/Wine. I suspect that the patch to vasnprintf.c is not the right way to go about things, but I don't know what the preferred method is. vsnprintf probably wants something similar. Comments? Index: lib/vasnprintf.c === RCS file: /sources/gnulib/gnulib/lib/vasnprintf.c,v retrieving revision 1.22 diff -u -p -r1.22 vasnprintf.c --- lib/vasnprintf.c30 Jan 2007 01:07:22 - 1.22 +++ lib/vasnprintf.c16 Feb 2007 05:01:05 - @@ -27,6 +27,9 @@ # include #endif +/* If we're replacing snprintf with rpl_snprintf, avoid a loop. */ +#undef snprintf + /* Specification. */ #if WIDE_CHAR_VERSION # include "vasnwprintf.h" Index: m4/snprintf.m4 === RCS file: /sources/gnulib/gnulib/m4/snprintf.m4,v retrieving revision 1.3 diff -u -p -r1.3 snprintf.m4 --- m4/snprintf.m4 23 Jan 2005 08:06:57 - 1.3 +++ m4/snprintf.m4 16 Feb 2007 05:01:06 - @@ -1,12 +1,27 @@ -# snprintf.m4 serial 2 -dnl Copyright (C) 2002, 2003, 2004 Free Software Foundation, Inc. +# snprintf.m4 serial 3 +dnl Copyright (C) 2002, 2003, 2004, 2007 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, dnl with or without modifications, as long as this notice is preserved. AC_DEFUN([gl_FUNC_SNPRINTF], [ - AC_REPLACE_FUNCS(snprintf) + AC_CACHE_CHECK([for C99-compliant snprintf], +[gl_cv_func_snprintf], +[AC_RUN_IFELSE( + [AC_LANG_PROGRAM( + [[#include ]], + [[char s[2]; +return !(snprintf (s, 2, "foo") == 3 && s[0] == 'f' && s[1] == '\0');]])], + [gl_cv_func_snprintf=yes], + [gl_cv_func_snprintf=no], + [gl_cv_func_snprintf=no])]) + + if test $gl_cv_func_snprintf = no; then +AC_LIBOBJ(snprintf) +AC_DEFINE(snprintf, rpl_snprintf, + [Define to rpl_snprintf if the replacement function should be used.]) + fi AC_CHECK_DECLS_ONCE(snprintf) gl_PREREQ_SNPRINTF ]) -- "In the PARTIES partition there is a small section called the BEER. Prior to turning control over to the PARTIES partition, the BIOS must measure the BEER area into PCR[5]." --TCPA PC Specific Implementation Specification
Re: check for C99-compliant snprintf
Paul Eggert <[EMAIL PROTECTED]> writes: > It's a bit of a pain that this will reject all cross-compiled snprintfs. > Is there some way you can test for this at compile-time? > > Does the nonstandard snprintf have exactly the same signature as the > C99 snprintf? If not, we should be able to catch this at > compile-time. > > Does the nonstandard implementation have a vsnprintf? If not, we > could test for that at link-time and cross-compiles wouldn't have to > substitute snprintf except on clearly pre-C99 systems. > > Basically, I'm looking for any way we can distinguish the nonstandard > implementation without running it. I agree that it would be nicer to distinguish the non-C99 snprintf at compile time. Unfortunately, the noncompliant snprintf has exactly the same signature and return value, and the system also has vsnprintf. 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
Re: check for C99-compliant snprintf
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 better idea?
>
> Do you mean to have two Autoconf tests, one at compile-time (with the
> above code), and one at run-time (with the code proposed earlier)?
> I.e., do the run-time test only if the compile-time test indicates
> that there may be trouble. That sounds a bit fancy, but it would
> work.
>
> Or, you could just do the compile-time test and assume the bug exists
> if it fails. That should be good enough, too.
The latter was what I had in mind. I've appended a revised patch
below, which takes that approach. To avoid duplicating the test
across snprintf and vsnprintf, I put the test into a separate
macro that is AC_REQUIREd.
This version works well for snprintf in my original test
environment, where I was using --disable-nls. But then when I
tested it along with libintl, I noticed that snprintf broke
again. I traced it to the following in libintl.h:
#undef snprintf
#define snprintf libintl_snprintf
where libintl_snprintf is a wrapper around the system snprintf,
which is still of course broken. I'm not sure how to work around
this problem. I guess I could submit a patch against the gettext
implementation of libintl_[v]snprintf to fix the problem, and
then recommend that mingw users of PSPP either --disable-nls or
use the fixed version. Does that sound like an effective
solution?
vsnprintf is problematic even with --disable-nls, because mingw
contains:
__CRT_INLINE int __cdecl
vsnprintf (char* s, size_t n, const char* format, __VALIST arg)
{ return _vsnprintf ( s, n, format, arg); }
When vsnprintf expands to rpl_vsnprintf, this turns rpl_vsnprintf
into a wrapper around the broken _vsnprintf. I chose to fix that
by also replacing _vsnprintf, as shown in the patch below. This
is all a little gross, and I don't know whether the method I used
is acceptable; please let me know.
Index: lib/_vsnprintf.c
===
RCS file: lib/_vsnprintf.c
diff -N lib/_vsnprintf.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lib/_vsnprintf.c17 Feb 2007 00:56:08 -
@@ -0,0 +1,19 @@
+/* Formatted output to strings.
+ Copyright (C) 2007 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY 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, Boston, MA 02110-1301, USA. */
+
+#define VSNPRINTF _vsnprintf
+#include "vsnprintf.c"
Index: lib/vasnprintf.c
===
RCS file: /sources/gnulib/gnulib/lib/vasnprintf.c,v
retrieving revision 1.22
diff -u -p -r1.22 vasnprintf.c
--- lib/vasnprintf.c30 Jan 2007 01:07:22 - 1.22
+++ lib/vasnprintf.c17 Feb 2007 00:56:09 -
@@ -27,6 +27,9 @@
# include
#endif
+/* If we're replacing snprintf with rpl_snprintf, avoid a loop. */
+#undef snprintf
+
/* Specification. */
#if WIDE_CHAR_VERSION
# include "vasnwprintf.h"
Index: lib/vsnprintf.c
===
RCS file: /sources/gnulib/gnulib/lib/vsnprintf.c,v
retrieving revision 1.3
diff -u -p -r1.3 vsnprintf.c
--- lib/vsnprintf.c 28 Aug 2006 16:04:14 - 1.3
+++ lib/vsnprintf.c 17 Feb 2007 00:56:09 -
@@ -37,13 +37,17 @@
# define EOVERFLOW E2BIG
#endif
+#ifndef VSNPRINTF
+# define VSNPRINTF vsnprintf
+#endif
+
/* Print formatted output to string STR. Similar to vsprintf, but
additional length SIZE limit how much is written into STR. Returns
string length of formatted string (which may be larger than SIZE).
STR may be NULL, in which case nothing will be written. On error,
return a negative value. */
int
-vsnprintf (char *str, size_t size, const char *format, va_list args)
+VSNPRINTF (char *str, size_t size, const char *format, va_list args)
{
char *output;
size_t len;
Index: m4/native-w32.m4
===
RCS file: m4/native-w32.m4
diff -N m4/native-w32.m4
--- /dev/null 1 Jan 1970 00:00:00 -
+++ m4/native-w32.m417 Feb 2007 00:56:09 -
@@ -0,0 +1,21 @@
Re: fix inadequate Windows implementation of tmpfile
Bruno Haible <[EMAIL PROTECTED]> writes: > Paul Eggert wrote: >> I think gnulib is for porting GNU applications, and if GNU >> applications assume glibc behavior for a function then it's OK to >> replace a vendor's function that behaves differrently. > > 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
conflicts between pathname.h and dirname.h
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
progreloc.c - what module?
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
Re: progreloc.c - what module?
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 pretty sure that the former is true. -- "Sanity is not statistical." --George Orwell
Re: Printf for gnulib?
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > Is there any interest in a full C99 printf in gnulib? Right now, > there's snprintf, vasnprintf, vasprintf, vsnprintf, and xvasprintf. > The problem with these is that they punt to the system's underlying > printf for some 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
Re: ///usr/include/stdlib.h:617: warning: '__malloc__' attribute ignored
Bruno Haible <[EMAIL PROTECTED]> writes: > I'm applying this: > > 2007-02-19 Bruno Haible <[EMAIL PROTECTED]> > > * lib/stdlib_.h: Use "#pragma GCC system_header" to suppress some gcc > warnings. > Reported by Joel E. Denny <[EMAIL PROTECTED]> via Paul Eggert. Would it be possible to apply a similar fix to string_.h? Under mingw, I see the following warnings when compiling a file that just contains the single line "#include ": [EMAIL PROTECTED]:~/pspp/mingw/pspp/_mingw/gl(0)$ i586-mingw32msvc-gcc -c -I. -Drestrict= -Wmissing-prototypes include-string.c In file included from ./string.h:23, from include-string.c:1: ///usr/lib/gcc/i586-mingw32msvc/3.4.5/../../../../i586-mingw32msvc/include/string.h:97: warning: no previous prototype for 'strcasecmp' ///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
Re: check for C99-compliant snprintf
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 program returns -1 on > Solaris 6/SPARC thru Solaris 9/SPARC which has vsnprintf(), for > example. It's not hard to check at runtime whether [v]snprintf is C99-compliant, as your example shows. A previous version of my proposed change did just that. Paul Eggert requested that I try to make it a compile- or link-time check, because the alternative was to assume that [v]snprintf needed to be replaced if we were cross-compiling. I wasn't aware that these other systems have non-compliant [v]snprintf, so I didn't check for them. Is it better to try to enumerate non-compliant systems at compile/link time, or to assume non-compliance when cross-compiling? Neither choice is ideal. What's more likely to be accepted into gnulib? -- On Perl: "It's as if H.P. Lovecraft, returned from the dead and speaking by seance to Larry Wall, designed a language both elegant and terrifying for his Elder Things to write programs in, and forgot that the Shoggoths didn't turn out quite so well in the long run." --Matt Olson
Re: check for C99-compliant snprintf
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 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 program returns -1 on
>> > Solaris 6/SPARC thru Solaris 9/SPARC which has vsnprintf(), for
>> > example.
>>
>> It's not hard to check at runtime whether [v]snprintf is
>> C99-compliant, as your example shows. A previous version of my
>> proposed change did just that. Paul Eggert requested that I try
>> to make it a compile- or link-time check, because the alternative
>> was to assume that [v]snprintf needed to be replaced if we were
>> cross-compiling. I wasn't aware that these other systems have
>> non-compliant [v]snprintf, so I didn't check for them.
>>
>> Is it better to try to enumerate non-compliant systems at
>> compile/link time, or to assume non-compliance when
>> cross-compiling? Neither choice is ideal. What's more likely to
>> be accepted into gnulib?
>
> How about assuming compliance when cross-compliance but enumerate,
> when cross-compiling, the systems that fail? When not cross-compiling,
> let's perform the compile-time check.
I'm willing to fix my proposed change so that it does this.
It appears, based on online documentation, that snprintf is C99
compliant in AIX 5.2 and above. Is that correct? If so, then
will the following successfully detect the systems with broken
snprintf:
#if defined _AIX && !defined _AIX52
/* broken */
#endif
How do you test for Solaris 6 through 9? The list at
predef.sf.net is not very helpful on this, because it doesn't
give any hint how to test for a range of Solaris versions, only
for particular versions.
--
Ben Pfaff
[EMAIL PROTECTED]
http://benpfaff.org
Re: progreloc.c - what module?
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 automake. Do you have time to work on that > with me? Yes, I have a little bit of time. It looks like you've done most of the work already. It seems that what is left is: - Prepare a gnulib module that encapsulates the lib and m4 files that are needed and makes the proper Autoconf calls. - Adding support to Automake to avoid the need to add or modify rules for relocatability. Does that look accurate? I'm willing to work on this, as it should be useful to me. -- "In this world that Hugh Heffner had made, he alone seemed forever bunnyless." --John D. MacDonald
Re: check for C99-compliant snprintf
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 support argument reordering
> on NetBSD and doesn't support %n on HP-UX? And an unchanged printf() and
> fprintf()?
I want a [v]snprintf that always null-terminates its output
string (if the size argument is greater than zero), so that I can
safely call [v]snprintf, then treat the result as a
null-terminated string without having to check the return value
at all. The pre-C99 [v]snprintfs don't necessarily do this, and
in particular Microsoft documents its _[v]snprintf to *not*
null-terminate if the output is too long.
> Please see the other mail ("Printf for gnulib") for a proposal
> how to get it all right.
Since there's momentum to fix all these problems at the same
time, I'll withdraw my proposal for a module, and work around the
problem for now.
--
Ben Pfaff
[EMAIL PROTECTED]
http://benpfaff.org
Re: fix inadequate Windows implementation of tmpfile
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 [EMAIL PROTECTED] just now. -- "Then, I came to my senses, and slunk away, hoping no one overheard my thinking." --Steve McAndrewSmith in the Monastery
Re: new module 'isnan-nolibm'
Bruno Haible <[EMAIL PROTECTED]> writes: > 2007-02-24 Bruno Haible <[EMAIL PROTECTED]> > > * modules/isnan-nolibm: New file. > * lib/isnan.h: New file. > * lib/isnan.c: New file. > * m4/isnan.m4: New file. Could/should this be merged into math_.h, so that there's no need for an additional #include "isnan.h"? -- Ben Pfaff [EMAIL PROTECTED] http://benpfaff.org
Re: new module 'isnan-nolibm'
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() without libm, it would make sense. 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 lacks it. So I'll drop the matter until I can. -- "Now I have to go wash my mind out with soap." --Derick Siddoway
Re: new module 'isnan-nolibm'
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 lacks it. > > The package I announced two days ago shows that most systems have isnan() > as a function: Clearly I should have paid better attention. I've taken better notice of that package now, so I'll check it before making more noise in the future. -- Ben Pfaff [EMAIL PROTECTED] http://benpfaff.org
Re: conflicts between pathname.h and dirname.h
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 go. :-)
>
> The GNU Coding Standards say that one shouldn't use the word
> "pathname" to describe file names.
>
> This issue is controversial, though -- as I recall, Bruno doesn't
> think internals like gnulib need to follow those standards.
Here is my attempt at a minimally invasive resolution of the
differences, which should be good enough to let both headers be
included at once. No code in gnulib/lib uses IS_ABSOLUTE_PATH or
IS_PATH_WITH_DIR from pathname.h, so it shouldn't affect anything
in gnulib.
I guess we'll see what Bruno thinks...
Index: lib/pathname.h
===
RCS file: /cvsroot/gnulib/gnulib/lib/pathname.h,v
retrieving revision 1.5
diff -u -p -r1.5 pathname.h
--- lib/pathname.h 14 May 2005 06:03:58 - 1.5
+++ lib/pathname.h 25 Feb 2007 06:24:29 -
@@ -1,5 +1,5 @@
/* Pathname support.
- Copyright (C) 2001-2004 Free Software Foundation, Inc.
+ Copyright (C) 2001-2004, 2007 Free Software Foundation, Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -18,35 +18,12 @@
#ifndef _PATHNAME_H
#define _PATHNAME_H
+#include "dirname.h"
+
#ifdef __cplusplus
extern "C" {
#endif
-
-/* Pathname support.
- ISSLASH(C) tests whether C is a directory separator character.
- IS_ABSOLUTE_PATH(P) tests whether P is an absolute path. If it is not,
-it may be concatenated to a directory pathname.
- IS_PATH_WITH_DIR(P) tests whether P contains a directory specification.
- */
-#if defined _WIN32 || defined __WIN32__ || defined __CYGWIN__ || defined
__EMX__ || defined __DJGPP__
- /* Win32, Cygwin, OS/2, DOS */
-# define ISSLASH(C) ((C) == '/' || (C) == '\\')
-# define HAS_DEVICE(P) \
-P)[0] >= 'A' && (P)[0] <= 'Z') || ((P)[0] >= 'a' && (P)[0] <= 'z')) \
- && (P)[1] == ':')
-# define IS_ABSOLUTE_PATH(P) (ISSLASH ((P)[0]) || HAS_DEVICE (P))
-# define IS_PATH_WITH_DIR(P) \
-(strchr (P, '/') != NULL || strchr (P, '\\') != NULL || HAS_DEVICE (P))
-# define FILE_SYSTEM_PREFIX_LEN(P) (HAS_DEVICE (P) ? 2 : 0)
-#else
- /* Unix */
-# define ISSLASH(C) ((C) == '/')
-# define IS_ABSOLUTE_PATH(P) ISSLASH ((P)[0])
-# define IS_PATH_WITH_DIR(P) (strchr (P, '/') != NULL)
-# define FILE_SYSTEM_PREFIX_LEN(P) 0
-#endif
-
/* Concatenate a directory pathname, a relative pathname and an optional
suffix. Return a freshly allocated pathname. */
extern char *concatenated_pathname (const char *directory,
Index: modules/pathname
===
RCS file: /cvsroot/gnulib/gnulib/modules/pathname,v
retrieving revision 1.2
diff -u -p -r1.2 pathname
--- modules/pathname22 Sep 2004 15:11:04 - 1.2
+++ modules/pathname25 Feb 2007 06:24:30 -
@@ -9,6 +9,7 @@ lib/concatpath.c
Depends-on:
xalloc
stpcpy
+dirname
configure.ac:
--
"J'avais trouv'e ma religion :
rien ne me parut plus important qu'un livre.
La biblioth`eque, j'y voyais un temple."
--Jean-Paul Sartre
Re: conflicts between pathname.h and dirname.h
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 'filename' (ex-'pathname') is to do > the most simple filename manipulations: analysis and concatenation. Why > should it depend on a module that defines functions base_name(), dir_name(), > last_component(), strip_trailing_slashes() ? It's not clear to me that concatenation is much simpler than extraction, but now I can use both headers at once, which is what I wanted. Thanks Bruno! -- Ben Pfaff [EMAIL PROTECTED] http://benpfaff.org
Re: first draft of "relocatable" module
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 used to >> > trigger this? e.g. something in AUTOMAKE_OPTIONS, a >> > magic AM_CONDITIONAL directive, something else? Being >> > no Automake guru I'm not sure what would be considered >> > in the "spirit of Automake" here. >> >> Ralf? > > Erm, just tell the user to add flags to AM_CFLAGS and AM_LDFLAGS? > Not sure what level of automation you're after, here, sorry. 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_PROGRAMS then the following is correct: foo_CFLAGS = -DINSTALLDIR=\"$(bindir)\" if RELOCATABLE_VIA_LD foo_LDFLAGS = `$(RELOCATABLE_LDFLAGS) $(bindir)` endif but if foo is in libexecdir_PROGRAMS then the following is needed instead: foo_CFLAGS = -DINSTALLDIR=\"$(libexecdir)\" if RELOCATABLE_VIA_LD foo_LDFLAGS = `$(RELOCATABLE_LDFLAGS) $(libexecdir)` endif That's why I'm asking for advice: I don't know how to do this gracefully. -- "There's only one thing that will make them stop hating you. And that's being so good at what you do that they can't ignore you. I told them you were the best. Now you damn well better be." --Orson Scott Card, _Ender's Game_
Re: first draft of "relocatable" module
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_PROGRAMS then the following is correct: >> >> foo_CFLAGS = -DINSTALLDIR=\"$(bindir)\" >> if RELOCATABLE_VIA_LD >> foo_LDFLAGS = `$(RELOCATABLE_LDFLAGS) $(bindir)` >> endif >> >> but if foo is in libexecdir_PROGRAMS then the following is needed >> instead: > > Ah, ok, thanks for the explanation. Yes, this may be best solved from > within Automake. Not sure if I have a chance to look at it soon though. Do you have a suggestion for a reasonable syntax to request it? I am willing to do some implementation work. -- "Platonically Evil Monkey has been symbolically representing the darkest fears of humanity since the dawn of literature and religion, and I think I speak for everyone when I give it a sidelong glance of uneasy recognition this evening." --Scrymarch
Re: new module 'isnan-nolibm'
Jim Meyering <[EMAIL PROTECTED]> writes: > Perhaps I should make gnus start reading via e.g., gmane.org. I recommend this approach. I read many mailing lists this way, and it works very well for me. I'm not sure how gmane chooses what to put in To: and CC:, but I've had no complaints so far. -- Ben Pfaff [EMAIL PROTECTED] http://benpfaff.org
Re: first draft of "relocatable" module
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. I'll follow up later with a fix for this and for compatibility problems pointed out by others. -- "Implementation details are beyond the scope of the Java virtual machine specification. One should not assume that every virtual machine implementation contains a giant squid." --"Mr. Bunny's Big Cup o' Java"
Re: first draft of "relocatable" module
Bruno Haible <[EMAIL PROTECTED]> writes: > -system library paths for security reasons. > +system library paths for security reasons. Also, installation with > [EMAIL PROTECTED] might not work not OpenBSD, when the > +package contains shared libraries and libtool versions 1.5.xx are used. Typo: "might not work not" => "might not work on" -- Ben Pfaff [EMAIL PROTECTED] http://benpfaff.org
Re: reorganize relocwrapper dependencies
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 the use > of different autoconf macros, and therefore the direct use of e.g. xreadlink.c > without going through module 'xreadlink'. OK. This makes sense. Thanks for doing this work. -- "The sound of peacocks being shredded can't possibly be any worse than the sound of peacocks not being shredded." Tanuki the Raccoon-dog in the Monastery
Re: first draft of "relocatable" module
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 Melissa license is a bit unclear, Melissa aggressively encourages free distribution of its source code." --Kevin Dalley <[EMAIL PROTECTED]>
Re: first draft of "relocatable" module
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
>> > 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$$.
>
> FWIW, I like that better, too. Or use some other path that only root
> can write to, like /opt or /nonexistent.
Here's some suggested wording then:
--- relocatable.texi.~1.3.~ 2007-03-03 12:23:49.0 -0800
+++ relocatable.texi2007-03-05 11:37:31.0 -0800
@@ -24,12 +24,16 @@ To configure a program to be relocatable
@option{--enable-relocatable} to the @program{configure} command line.
For reliability, it is best to also give a @option{--prefix} option
pointing to an otherwise unused (and never used again) directory,
-e.g.@: @option{--prefix=/tmp/inst$$}. This is recommended because on
+e.g.@: @option{--prefix=$HOME/inst$$} or
[EMAIL PROTECTED]/nonexistent}. This is recommended because on
some OSes the executables remember the location of shared libraries
and prefer them over any other search path. Therefore, such an
executable will look for its shared libraries first in the original
installation directory and only then in the current installation
-directory.
+directory. Locations writable by unprivileged users, such as
[EMAIL PROTECTED]/tmp/inst$$}, are not recommended because such users can
+re-create a directory with the same name after the original directory
+has been removed.
Installation with @option{--enable-relocatable} will not work for
setuid or setgid executables, because such executables search only
--
"...dans ce pays-ci il est bon de tuer de temps en temps un amiral
pour encourager les autres."
--Voltaire, _Candide_
Re: first draft of "relocatable" module
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 an NFS automounter, and your program searches for anything
> in its $prefix, then this can slow things to a crawl.
Good point. Here's some better wording taking that into account:
*** relocatable.texi.~1.3.~ 2007-03-03 12:23:49.0 -0800
--- relocatable.texi2007-03-05 11:54:53.0 -0800
***
*** 22,35
To configure a program to be relocatable, add
@option{--enable-relocatable} to the @program{configure} command line.
! For reliability, it is best to also give a @option{--prefix} option
! pointing to an otherwise unused (and never used again) directory,
! e.g.@: @option{--prefix=/tmp/inst$$}. This is recommended because on
! some OSes the executables remember the location of shared libraries
and prefer them over any other search path. Therefore, such an
executable will look for its shared libraries first in the original
installation directory and only then in the current installation
! directory.
Installation with @option{--enable-relocatable} will not work for
setuid or setgid executables, because such executables search only
--- 22,54
To configure a program to be relocatable, add
@option{--enable-relocatable} to the @program{configure} command line.
!
! On some OSes the executables remember the location of shared libraries
and prefer them over any other search path. Therefore, such an
executable will look for its shared libraries first in the original
installation directory and only then in the current installation
! directory. Thus, for reliability, it is best to also give a
! @option{--prefix} option pointing to a directory that does not exist
! now and which never will be created, e.g.@:
! @option{--prefix=/nonexistent}. You may use
! @[EMAIL PROTECTED] on the @program{make} command line to
! avoid installing into that directory.
!
! We do not recommend using a prefix writable by unprivileged users
! (e.g.@: @file{/tmp/inst$$}) because such a directory can be recreated
! by an unprivileged user after the original directory has been removed.
! We also do not recommend prefixes that might be behind an automounter
! (e.g.@: @file{$HOME/inst$$}) because of the performance impact of
! directory searching.
!
! Here's a sample installation run that takes into account all these
! recommendations:
!
! @example
! ./configure --enable-relocatable --prefix=/nonexistent
! make
! make install DESTDIR=/tmp/inst$$
! @end example
Installation with @option{--enable-relocatable} will not work for
setuid or setgid executables, because such executables search only
--
Positronic Functional Android Fabricated for Fighting
Re: identifiers in header files
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 "#define x char *". >> Other gnulib .h files (e.g., time.h) work around this problem by >> prefixing the parameters with double-underscore > > You are looking at it from the perspective of a gnulib user who wants a > but the freedom to use identifiers like 'x' and '_x' completely > freely. According to this perspective, gnulib should not use 'x' or '_x'. > > The other perspective is from the libc vendors. For them, gnulib is violating > their territory of identifiers if gnulib uses identifiers like '__x'. Gnulib could carve out its own name space by using gl_x (or whatever) instead of x or __x. -- "Then, I came to my senses, and slunk away, hoping no one overheard my thinking." --Steve McAndrewSmith in the Monastery
Re: Membership request for group gnulib - GNU portability library
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 functions, which GNU PSPP wants and I've started work on but never finished. Then, anything else wanted by GNU PSPP; I'm not sure what at the moment. -- "I was born lazy. I am no lazier now than I was forty years ago, but that is because I reached the limit forty years ago. You can't go beyond possibility." --Mark Twain
Re: adding bootstrap and bootstrap.conf
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 project named "autogen" that is not, as far as I know, related to "autogen.sh". -- "I don't want to learn the constitution and the declaration of independence (marvelous poetry though it be) by heart, and worship the flag and believe that there is a god and the dollar is its prophet." --Maarten Wiltink in the Monastery
Re: first draft of "relocatable" module
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 an NFS automounter, and your program searches for anything > in its $prefix, then this can slow things to a crawl. and I wrote again even later (in a message visible as http://permalink.gmane.org/gmane.comp.lib.gnulib.bugs/9525): > Good point. Here's some better wording taking that into account: and seeing no further discussion, I checked it in just now. -- "Now I have to go wash my mind out with soap." --Derick Siddoway
Re: [patch] doc/gnulib.texi typofix
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
Re: support for bitwise comparison of floats
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;
>>> long l;
>>> } u;
>>> u.d = d;
>>> u.l |= 1;
>>> return u.d < 0;
>>> }
>>> return d < 0;
>>> }
[...]
>> It's safer to use u.l |= 8; since noone will put the sign bit at
>> bit 3 or 28 (except the HP-PA designers perhaps :-)).
>
> Yes, I like your idea of using a bit other than the LSB as a way to ensure
> that the sign bit is not hit. But you also have to pick a bit that does
> not fall in the 2-byte padding of the 10-byte x86 long double.
I think that you can detect that you hit the padding by testing
whether u.d == 0. If it's still 0, then you changed a padding
bit.
--
I love deadlines.
I love the whooshing noise they make as they go by.
--Douglas Adams
Re: new module 'fpieee'
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 compiler to emit different (more expensive) > floating-point instructions. This module implements it. Is this also necessary on SH systems? The GCC manual has this in the page specific to SH: `-mieee' Increase IEEE-compliance of floating-point code. At the moment, this is equivalent to `-fno-finite-math-only'. When generating 16 bit SH opcodes, getting IEEE-conforming results for comparisons of NANs / infinities incurs extra overhead in every floating point comparison, therefore the default is set to `-ffinite-math-only'. In GNU PSPP, I have a configure test that just checks whether the compiler accepts -mieee and uses it if it is available. I wonder whether this is an approach that is more likely to automatically work as architectures appear. Here's what PSPP is using: dnl Check whether a C compiler option is accepted. dnl If so, add it to CFLAGS. dnl Example: PSPP_ENABLE_OPTION(-Wdeclaration-after-statement) AC_DEFUN([PSPP_ENABLE_OPTION], [ m4_define([pspp_cv_name], [pspp_cv_[]m4_translit([$1], [-], [_])])dnl AC_CACHE_CHECK([whether $CC accepts $1], [pspp_cv_name], [pspp_save_CFLAGS="$CFLAGS" CFLAGS="$CFLAGS $1" AC_COMPILE_IFELSE([AC_LANG_PROGRAM(,)], [pspp_cv_name[]=yes], [pspp_cv_name[]=no]) CFLAGS="$pspp_save_CFLAGS"]) if test $pspp_cv_name = yes; then CFLAGS="$CFLAGS $1" fi ]) ... PSPP_ENABLE_OPTION(-mieee) -- Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;) -- Linus Torvalds
Re: seekable stdin test failure on OS X
"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]
Re: seekable stdin test failure on OS X
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 documents. In > the late 1980s the POSIX committee decided that fflush (stdin) should > flush the input buffer and (on seekable devices) restore the input > position on the underyling file descriptor to match the position in > the stream. At some point in the mid-1990s this requirement was > weakened to be more like (but not exactly like) ISO C89. However, in > the latest POSIX it's stronger again, and is more like the late 1980s. Is there a version of POSIX newer than "The Open Group Base Specifications Issue 6: IEEE Std 1003.1, 2004 Edition"? This version doesn't say anything about the behavior of fflush for input streams, or at least it doesn't on the page dedicated to fflush. > Anyway, for what it's worth I think fflush (stdin) should behave like > 1988 POSIX and glibc, at least for apps that care about this sort of > thing. If apps want that behavior then it entirely makes sense to implement it (and I really shouldn't have stuck my oar in). I'm surprised that glibc implements this behavior for fflush on input streams: the glibc manual I have here doesn't mention it. But I can see in the libio sources that glibc does do it. -- Ben Pfaff [EMAIL PROTECTED]
Re: new module 'iconv_open'
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 end of a single configure run, instead of just failing the configure run after finding the first missing prerequisite library. It would be a natural extension to apply this to helper tools such as gperf. -- "Unix... is not so much a product as it is a painstakingly compiled oral history of the hacker subculture." --Neal Stephenson
iconv_open module need $(srcdir) in Makefile fragment
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? --- gnulib/modules/iconv_open.~1.1.~2007-03-31 14:00:19.0 -0700 +++ gnulib/modules/iconv_open 2007-04-03 16:49:40.0 -0700 @@ -36,17 +36,17 @@ iconv.h: iconv_.h MOSTLYCLEANFILES += iconv.h iconv.h-t GPERF = gperf -iconv_open-aix.h: iconv_open-aix.gperf - $(GPERF) -m 10 iconv_open-aix.gperf > [EMAIL PROTECTED] +iconv_open-aix.h: $(srcdir)/iconv_open-aix.gperf + $(GPERF) -m 10 $(srcdir)/iconv_open-aix.gperf > [EMAIL PROTECTED] mv [EMAIL PROTECTED] $@ -iconv_open-hpux.h: iconv_open-hpux.gperf - $(GPERF) -m 10 iconv_open-hpux.gperf > [EMAIL PROTECTED] +iconv_open-hpux.h: $(srcdir)/iconv_open-hpux.gperf + $(GPERF) -m 10 $(srcdir)/iconv_open-hpux.gperf > [EMAIL PROTECTED] mv [EMAIL PROTECTED] $@ -iconv_open-irix.h: iconv_open-irix.gperf - $(GPERF) -m 10 iconv_open-irix.gperf > [EMAIL PROTECTED] +iconv_open-irix.h: $(srcdir)/iconv_open-irix.gperf + $(GPERF) -m 10 $(srcdir)/iconv_open-irix.gperf > [EMAIL PROTECTED] mv [EMAIL PROTECTED] $@ -iconv_open-osf.h: iconv_open-osf.gperf - $(GPERF) -m 10 iconv_open-osf.gperf > [EMAIL PROTECTED] +iconv_open-osf.h: $(srcdir)/iconv_open-osf.gperf + $(GPERF) -m 10 $(srcdir)/iconv_open-osf.gperf > [EMAIL PROTECTED] mv [EMAIL PROTECTED] $@ BUILT_SOURCES+= iconv_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]
Re: iconv_open module need $(srcdir) in Makefile fragment
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. -- "I was born lazy. I am no lazier now than I was forty years ago, but that is because I reached the limit forty years ago. You can't go beyond possibility." --Mark Twain
Re: new module 'iconv_open'
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 >> first missing prerequisite library. It would be a natural >> extension to apply this to helper tools such as gperf. > > But then you would display that 'gperf' and 'bison' are missing tools, > also to the user of a tarball that contains the generated files already. You're right, I missed that. Never mind. -- Ben Pfaff [EMAIL PROTECTED]
