split stdio-safer into fopen-safer, tmpfile-safer

2006-07-25 Thread Paul Eggert
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

Re: va_copy, new module 'stdarg'

2006-07-25 Thread Bruno Haible
Jim Meyering wrote: The stdarg.m4 macro is now tested (it's used in gettext-0.15). Any objections to this patch? That looks fine. Patch applied. 2006-07-25 Bruno Haible [EMAIL PROTECTED] * modules/version-etc (Depends-on): Add stdarg. * lib/version-etc.c

Re: shell variable namespaces

2006-07-25 Thread Jim Meyering
Bruno Haible [EMAIL PROTECTED] wrote: Jim Meyering wrote: I see that there are many other uses of $result in that file. How about using a name that doesn't impinge on the configure.ac writer's name space? E.g., s/result/gl_result/g in stdint.m4 There are many more shell variables used in

Re: split stdio-safer into fopen-safer, tmpfile-safer

2006-07-25 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 7/25/2006 12:24 AM: 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: Reasonable. In fact, it

Re: split stdio-safer into fopen-safer, tmpfile-safer

2006-07-25 Thread Ben Pfaff
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

Re: stdint.m4 tweak

2006-07-25 Thread Paul Eggert
Bruno Haible [EMAIL PROTECTED] writes: ok to apply this code simplification? That's fine with me, thanks. (Though I wrote it that way so I wouldn't have to worry about the issue of namespace collision. So maybe it's simpler the way it is. :-)

Re: purpose of *-safer?

2006-07-25 Thread Bruno Haible
Hi Paul, When is it recommended to use these *-safer modules? What I understand is: If one of the file descriptors 0, 1, 2 is closed at program startup, and if you later use open() or fopen(), it might be possible that printf or fprintf statements to stdout or stderr are directed into this

Re: rewritten inttypes module

2006-07-25 Thread Paul Eggert
Thanks very much for tackling this! It will clean up quite a bit of code. Some comments: Bruno Haible [EMAIL PROTECTED] writes: + #if !defined PRId8 || PRI_MACROS_BROKEN + # undef PRId8 + # define PRId8 d + #endif C99 says macro definitions like this should be skipped if C++, unless

Re: making stdint.m4 stricter

2006-07-25 Thread Paul Eggert
Bruno Haible [EMAIL PROTECTED] writes: 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? Yes, thanks.

Re: purpose of *-safer?

2006-07-25 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 7/25/2006 2:05 PM: Hi Paul, When is it recommended to use these *-safer modules? What I understand is: If one of the file descriptors 0, 1, 2 is closed at program startup, and if you later use open() or fopen(), it

Re: split stdio-safer into fopen-safer, tmpfile-safer

2006-07-25 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ben Pfaff on 7/25/2006 11:21 AM: 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,