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:
2006-07-24 Paul Eggert <[EMAIL PROTECTED]>
* MODULES.html.sh (File stream based Input/Output):
Add fopen-s
Paul Eggert wrote:
> Linus Torvalds has deprecated the use of 'volatile' in data
> structures for optimization barriers (which is the use that started
> this thread), and prefers the use of primitives like barrier()
> instead.
Sure, I agree that it's easier to write wrong code with 'volatile'
than
Forgot to update the dependencies of the javacomp module.
2006-07-24 Bruno Haible <[EMAIL PROTECTED]>
* modules/javacomp (Depends-on): Add unistd, javaversion, binary-io,
getline, pathname, fwriteerror, clean-temp, xvasprintf, strstr.
*** modules/javacomp2 Dec 2005 17:55:34
Bruno Haible <[EMAIL PROTECTED]> writes:
> The Intel compiler people also have the declared goal of supporting the
> Linux kernel. They spent a lot of effort adding support for __asm__ in gcc's
> semantics; I don't think they would drop this support for a different
> semantics of 'volatile'.
Sure
Hi,
I'm adding the clean-temp module. Since take 1, I did the following
modifications:
- The functions were renamed from enqueue_*/dequeue_* to
register_*/unregister_*.
- create_temp_dir takes additional arguments parentdir, cleanup_verbose,
both so that the module can be used in GNU s
Hi,
The clean-temp module needs to separate the step of the pathname template
generation from the actual creation of the directory (for the sake of
good error handling). The code comes from glibc's tempname.c; unfortunately
it's not structured adequately (but rather optimized for minimum code size
Hi,
I committed this patch, using 'volatile' to avoid instruction reordering.
2006-07-23 Bruno Haible <[EMAIL PROTECTED]>
* gl_anylinked_list2.h (ASYNCSAFE): New macro.
(gl_linked_add_first, gl_linked_add_last, gl_linked_add_before,
gl_linked_add_after, gl_linked_add_a
Hi,
After the complete stdint module, and now that gettext has renamed its
earlier inttypes.m4 macro file, we're now ready for a complete
replacement. The proposed rewrite consists of 5 modules:
- inttypes provides only the header file ,
- imaxabs, imaxdiv provide just t
Hi Paul,
It doesn't cost much add verify that the *_MIN macros are defined in
stdint.m4 (even if I haven't seen a system that defines *_MAX but not
the corresponding *_MIN). Likewise for the INT_LEAST_*_MAX/MIN macros.
OK to commit?
*** gnulib-20060722/m4/stdint.m42006-07-11 13:54:20.000
Hi Paul,
ok to apply this code simplification?
diff -r -c3 --unidirectional-new-file --exclude=CVS
gnulib-20060722/m4/stdint.m4 gnulib-20060722-modified/m4/stdint.m4
*** gnulib-20060722/m4/stdint.m42006-07-11 13:54:20.0 +0200
--- gnulib-20060722-modified/m4/stdint.m4 2006-0
Hi Jim,
The stdarg.m4 macro is now tested (it's used in gettext-0.15). Any objections
to this patch?
diff -r -c3 --unidirectional-new-file --exclude=CVS
gnulib-20060722/modules/version-etc gnulib-20060722-modified/modules/version-etc
*** gnulib-20060722/modules/version-etc 2005-07-06 17:58:47.0
For the javacomp module, it is necessary to know which java version
the java executer understands. (That means both the bytecoded class
version number as well as the API level.)
I added this new module.
= modules/javaversion
Description:
Determ
Paul Eggert wrote:
> > 'malloc' is one such function.
>
> My intuition is the oppposite; I would expect 'malloc' to have more
> problems than a random user function, since the compiler "knows" more
> of malloc's properties.
The compiler knows about it, but its code is quite complex, therefore hard
Paul Eggert wrote:
> I noticed that recent changes (merging from gettext, for example)
> added many ChangeLog entries whose dates disagree with when the change
> was installed into gnulib. Hence gnulib's ChangeLog file appears not
> to be in reverse chronological order. This confused me.
>
> Whe
14 matches
Mail list logo
