Re: stdint.m4 tweak
Bruno Haible <[EMAIL PROTECTED]> wrote:
> 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.m4 2006-07-11 13:54:20.0 +0200
> --- gnulib-20060722-modified/m4/stdint.m4 2006-07-23 03:00:45.0
> +0200
> ***
> *** 296,302
> extern $gltype foo;
> extern $gltype1 foo;])],
> [eval gl_cv_type_${gltype}_suffix=\$glsuf])
> ! eval test \"\$gl_cv_type_${gltype}_suffix\" != no && break
> done])
> GLTYPE=`echo $gltype | tr 'abcdefghijklmnopqrstuvwxyz '
> 'ABCDEFGHIJKLMNOPQRSTUVWXYZ_'`
> eval result=\$gl_cv_type_${gltype}_suffix
> --- 321,328
> extern $gltype foo;
> extern $gltype1 foo;])],
> [eval gl_cv_type_${gltype}_suffix=\$glsuf])
> ! eval result=\$gl_cv_type_${gltype}_suffix
> ! test "$result" != no && break
> done])
> GLTYPE=`echo $gltype | tr 'abcdefghijklmnopqrstuvwxyz '
> 'ABCDEFGHIJKLMNOPQRSTUVWXYZ_'`
> eval result=\$gl_cv_type_${gltype}_suffix
Hi Bruno,
That looks like a fine simplification.
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
Re: va_copy, new module 'stdarg'
Bruno Haible <[EMAIL PROTECTED]> wrote: > The stdarg.m4 macro is now tested (it's used in gettext-0.15). Any objections > to this patch? That looks fine. Thank you!
Re: va_copy, new module 'stdarg'
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 (version_etc_va): Use va_copy, assumed to be defined in or config.h.
Re: [bug-gnulib] shell variable namespaces
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 macros that don't have a particular prefix. acl.m4 use_acl csharpcomp.m4 error eoverflow.m4have_eoverflow gc.m4 libgcrypt gettext.m4 is_woe32dll host-os.m4 os intdiv0.m4 value javacomp.m4 source_version target_version goodcode failcode \ cfversion lib-link.m4 with_gnu_ld wl libext shlibext \ hardcode_libdir_flag_spec hardcode_libdir_separator \ hardcode_direct hardcode_minus_L enable_rpath \ use_additional additional_includedir \ additional_libdir rpathdirs ltrpathdirs \ names_already_handled names_next_round \ names_this_round already_handled uppername value \ found_dir found_la found_so found_a haveit basedir \ dir alldirs next lib-prefix.m4 searchpath ls-mntd-fs.m4 getfsstat_includes nanosleep.m4nanosleep_save_libs perl.m4 candidate_perl_names perl_specified found po.m4 srcdirpre useit desiredlanguages lang frobbedlang \ presentlang ptrdiff_max.m4 result signalblocking.m4 signals_not_posix size_max.m4 result stdint.m4 result 1) Do you think it's worth to change them all? Did you experience a collision between your variables in configure.ac and one in *.m4? 2) When using such namespaces, moving macros from/to gnulib needs renamings. Unnecessary diffs. Bruno
Re: shell variable namespaces
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 macros that don't have a > particular prefix. > > acl.m4 use_acl > csharpcomp.m4 error > eoverflow.m4have_eoverflow > gc.m4 libgcrypt > gettext.m4 is_woe32dll > host-os.m4 os > intdiv0.m4 value > javacomp.m4 source_version target_version goodcode failcode \ > cfversion > lib-link.m4 with_gnu_ld wl libext shlibext \ > hardcode_libdir_flag_spec hardcode_libdir_separator \ > hardcode_direct hardcode_minus_L enable_rpath \ > use_additional additional_includedir \ > additional_libdir rpathdirs ltrpathdirs \ > names_already_handled names_next_round \ > names_this_round already_handled uppername value \ > found_dir found_la found_so found_a haveit basedir \ > dir alldirs next > lib-prefix.m4 searchpath > ls-mntd-fs.m4 getfsstat_includes > nanosleep.m4nanosleep_save_libs > perl.m4 candidate_perl_names perl_specified found > po.m4 srcdirpre useit desiredlanguages lang frobbedlang \ > presentlang > ptrdiff_max.m4 result > signalblocking.m4 signals_not_posix > size_max.m4 result > stdint.m4 result Thanks for identifying those. > 1) Do you think it's worth to change them all? Did you experience a >collision between your variables in configure.ac and one in *.m4? Yes, I have experienced collisions (though none recently). That's why I brought it up. They are far more likely with short and generic names like $found, $result and $dir. Although I wouldn't worry about the long ones, it would be nice to rename them use a prefix, too. > 2) When using such namespaces, moving macros from/to gnulib needs renamings. >Unnecessary diffs. IMHO, the important thing is that there be *some* prefix. Having a mix of e.g., gl_ and gt_ prefixes shouldn't cause trouble.
Re: split stdio-safer into fopen-safer, tmpfile-safer
-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 means that people using "stdio--.h" now have the added benefit of getting a link error if they use 'tmpfile' but did not import the 'tmpfile-safer' module. This can be construed as a feature to make people avoid tmpfile. (For the upcoming m4 1.4.6, it was too invasive to a stable branch to rework the code to avoid tmpfile; but for CVS head and the future m4 2.0, I agree with your sentiment that it is better to avoid tmpfile). Would you accept a similar patch that splits out pipe-safer into its own module instead of part of unistd-safer? Since pipe is not available on mingw, I currently get compile-time warnings when compiling m4 on mingw, but only because pipe-safer.c is using an undefined function, and not because m4 is using pipe. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFExg+H84KuGfSFAYARAjTRAJ9O6fEd/QoXGLOYzr0c0OBe1r/I/wCbBR4S HRjIx2cNaEKKqy0O80SYEXM= =iBqO -END PGP SIGNATURE-
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: stdint.m4 tweak
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?
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 completely unrelated file.
But when does this occur? Does 'sh' or 'bash' invoke programs in this
state? Does Apache do so when running cgi-bin programs?
It is regarded as antisocial if a program starts another program with
some file descriptors in O_NONBLOCK mode. Or when a program starts
another program with a nonzero mask of ignored signals (sigprocmask).
Isn't passing closed descriptors 0, 1, or 2, of the same category?
And wouldn't there be an easier workaround: At the beginning of main(),
use fcntl() to determine whether 0,1,2 are closed, and if so, replace
them with open("/dev/null") ?
Just asking because I'm wondering whether not using these modules
in GNU gettext leads to bugs.
Bruno
Re: rewritten inttypes module
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
__STDC_FORMAT_MACROS is defined. Also, the macro should be defined
only if the corresponding type exists (this is relevant only on weird,
perhaps nonexistent, hosts that have stdint.h but not inttypes.h, but
we might as well do things right). Perhaps something like this
instead?
#if !defined PRId8 || PRI_MACROS_BROKEN
# undef PRId8
# if !defined __cplusplus || defined __STDC_FORMAT_MACROS
# ifdef INT8_MAX
# define PRId8 "d"
# endif
# endif
#endif
Similarly for the other optional types, e.g., intptr_t, int64_t.
> + #if !defined PRIdFAST8 || PRI_MACROS_BROKEN
> + # undef PRIdFAST8
> + # if INT_FAST8_MAX > INT32_MAX
> + # define PRIdFAST8 PRId64
> + # else
> + # define PRIdFAST8 "d"
> + # endif
> + #endif
Shouldn't that be "INT_FAST8_MAX > INT_MAX"? Similarly for the other
macros. Something like this might be a bit more robust:
#if !defined PRIdFAST8 || PRI_MACROS_BROKEN
# undef PRIdFAST8
# if !defined __cplusplus || defined __STDC_FORMAT_MACROS
# if INT_FAST8_MAX <= INT_MAX
# define PRIdFAST8 "d"
# elif INT_FAST8_MAX <= LONG_MAX
# define PRIdFAST8 "ld"
# else
# define PRIdFAST8 PRId64
# endif
# endif
#endif
> + /* Don't bother defining or declaring wcstoimax and wcstoumax, since
> +wide-character functions like this are hardly useful. */
hardly useful -> hardly ever useful
> + #include
> + #define __STDC_LIMIT_MACROS 1 /* to make it work also in C++ mode */
Need to define __STDC_FORMAT_MACROS here too.
> + #include ABSOLUTE_INTTYPES_H
> + /* Same tests as in stdint.m4. */
Shouldn't these common tests be factored out? Or perhaps it's be
simpler and faster to look at gl_cv_header_working_stdint_h; if it is
not 'yes' then you can assume that inttypes.h is broken too. That's a
fairly safe assumption, I'd think (and even if it's wrong we're merely
generating inttypes.h when we don't have to).
> + /* Tests for macros supposed to be defined in inttypes.h. */
> +
> + const char *k = /* implicit string concatenation */
> + PRId8 PRIi8 PRIo8 PRIu8 PRIx8 PRIX8
> + PRId16 PRIi16 PRIo16 PRIu16 PRIx16 PRIX16
> + PRId32 PRIi32 PRIo32 PRIu32 PRIx32 PRIX32
The above test macros also need protecting inside #ifdef.
> + #ifdef INT64_MAX
> + PRId64 PRIi64
> + #endif
> + PRIdPTR PRIiPTR PRIoPTR PRIuPTR PRIxPTR PRIXPTR
These need protecting inside ifdef.
Also, since we want to cater to C89 hosts without a 64-bit type, we
need to put macros like PRIdLEAST64 inside an ifdef too, even though
C99 requires these macros. Otherwise our implementation wouldn't pass
our own test. (This suggests a natural test case, I suppose)
I don't see why the changes to lib/stdint_.h, m4/stdint.m4, and
modules/stdint are needed. They have an effect only if we use
gnulib's inttypes.h and gnulib's stdint.h. If the program includes
inttypes.h first, this includes stdint.h, which in turn recursively
includes inttypes.h, but this innermost include is a noop because
INTTYPES_H is defined. A similar argument occurs if the program
includes stdint.h first, with _GL_STDINT_H. It makes 'configure' run
faster if we omit these changes.
> + if (!(denom == 0 || (denom == -1 && numer < 0 && - numer < 0)))
This code is attempting to check for undefined behavior, but it in
turn relies on undefined behavior since '- numer' has undefined
behavior when numer < -INTMAX_MAX. I doubt whether it's worth the
trouble to call 'abort' on undefined behavior, as it's too much pain
to do this portably; we can simply have undefined behavior, as that's
good enough.
Also, the code assumes C99 division behavior, but since gnulib
only assumes C89 the code should defend itself against this.
How about if we use something like the following instead?
(I haven't tested this.)
imaxdiv_t
imaxdiv (intmax_t numer, intmax_t denom)
{
imaxdiv_t result;
result.quot = numer / denom;
result.rem = numer % denom;
/* C89 allows division to take either the ceiling or the floor if
either operand is negative, but C99 requires truncation towards
zero. Adjust C89's results to match C99, if necessary. */
if (result.rem != 0)
{
if ((numer < 0) == (denom < 0))
{
if ((denom < 0) != (result.rem < 0))
{
result.quot--;
result.rem += denom;
}
}
else
{
if ((denom < 0) == (result.rem < 0))
{
result.quot++;
result.rem -= denom;
}
}
}
return result;
}
Re: making stdint.m4 stricter
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?
-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
> might be possible that printf or fprintf statements to stdout or stderr
> are directed into this completely unrelated file.
>
> But when does this occur? Does 'sh' or 'bash' invoke programs in this
> state? Does Apache do so when running cgi-bin programs?
It can. POSIX requires [n]>&- and [n]<&- redirection operators to close
the respective stream, even when n is 0, 1, or 2. POSIX allows an
implementation to supply replacement file descriptors when exec'ing a
setuid or setgid program. But in the normal case, implementations really
do allow you to start life with any of the three standard streams closed.
>
> It is regarded as antisocial if a program starts another program with
> some file descriptors in O_NONBLOCK mode. Or when a program starts
> another program with a nonzero mask of ignored signals (sigprocmask).
> Isn't passing closed descriptors 0, 1, or 2, of the same category?
Yes, but that doesn't mean GNU programs can't be robust against it.
>
> And wouldn't there be an easier workaround: At the beginning of main(),
> use fcntl() to determine whether 0,1,2 are closed, and if so, replace
> them with open("/dev/null") ?
Possibly. And if we did, it would make more sense to open fd 0 as write
only and fd 1 as read only, to be more likely to catch attempts to use
these streams when the user intended them to be closed. But it is nicer
to have the error message reflect the actual situation of EBADF. And in
some cases, the fact that the stream is closed is harmless (such as cp a b
>&-, which produced no output).
>
> Just asking because I'm wondering whether not using these modules
> in GNU gettext leads to bugs.
Possibly. See my thread in m4 for the types of bugs I just fixed by using
the -safer modules.
http://lists.gnu.org/archive/html/bug-m4/2006-07/msg00021.html
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFExruD84KuGfSFAYARAreyAJwLuG859fNR44VfzT+mo+uwc9+8hgCfb1Uc
LwhoCjSNaXYVtk7pjhA24Ak=
=NFFm
-END PGP SIGNATURE-
Re: split stdio-safer into fopen-safer, tmpfile-safer
-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, as follows: > > Can you expand on why tmpfile is not so safe? I'd still like to fear Paul's reasons. 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). - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFExr3V84KuGfSFAYARAiGtAJ436Q7fwr4KZnhLPcXNTjxU6jaPdACeNDR9 y9o+G31/rrjQGu2sU3GcQq4= =IsUK -END PGP SIGNATURE-
