Re: [bug-gnulib] Re: ISSLASH on Woe32
Hello, Ian Abbott asked: > > Could this also be a problem on Unix systems using multibyte encoded > > (UTF-8) filesystems, if not now then in the future? no, this cannot happen, because of how UTF-8 is designed: 1) If a character is represented by a single byte, then the the most significant bit is not set, and the byte is the same as in ASCII. In other words, the 7bit ASCII is part of UTF-8. 2) If a character is represented by a sequence of bytes, then each of these bytes has the most significant bit set. (Thus no '/' can appear there.) [I'd like to thank to Jakub Jelinek for teaching me this.] Paul said: > I doubt it. Historically Unix has always used bytes, not characters, > to name files. So it doesn't care about your encoding. I doubt > whether this will ever change. Paul, your intuition was right. Actually, using utf-8 for filenames prevents this problem in principle. Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] improve gnulib-tool output
Hello, I noticed a minor problem here. (It was also present in the previous version: On Fri, May 13, 2005 at 12:04:35AM -0700, Paul Eggert wrote: > ... | sed -e '/^$/d;' -e 's/^/ /' I'd use either sed '/^$/d;s/^/ /' or sed -e '/^$/d' -e 's/^/ /' I'm afraid that the extra semicolon could cause problems with some seds. Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] Re: gcc -Wall warning for minmax.h
Hi Bruno, I read your macro in minmax.m4. I'd like to propose some changes in style: - avoid the obsoleted AC_TRY_COMPILE - use m4_pushdef/m4_popdef instead of define/undefine - use AS_TR_* instead of raw m4_translit A patch with my proposal is attached; it's not tested, sorry. Could you please find some time to look at it? [FYI: I'll be offline Jun 7 - Jun 21.] Have a nice day, Stepan 2005-06-03 Stepan Kasal <[EMAIL PROTECTED]> * minmax.m4 (gl_MINMAX_IN_HEADER): Use more modern macros. Index: m4/minmax.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/minmax.m4,v retrieving revision 1.1 diff -u -r1.1 minmax.m4 --- m4/minmax.m423 May 2005 10:25:53 - 1.1 +++ m4/minmax.m43 Jun 2005 11:53:03 - @@ -19,20 +19,19 @@ dnl gl_MINMAX_IN_HEADER(HEADER) AC_DEFUN([gl_MINMAX_IN_HEADER], [ - define([header],[translit([$1],[./-], - [___])]) - define([HEADER],[translit([$1],[abcdefghijklmnopqrstuvwxyz./-], - [ABCDEFGHIJKLMNOPQRSTUVWXYZ___])]) + AC_PREREQ(2.50) + AS_LITERAL_IF([$1], [], +[m4_fatal([gl_MINMAX_IN_HEADER requires a literal parameter.])]) + m4_pushdef([gl_CACHE_VAR], gl_cv_minmax_in_[]AS_TR_SH([$1])) AC_CACHE_CHECK([whether <$1> defines MIN and MAX], -[gl_cv_minmax_in_]header, -[AC_TRY_COMPILE([#include <$1> -int x = MIN (42, 17);], [], - [gl_cv_minmax_in_]header[=yes], - [gl_cv_minmax_in_]header[=no])]) - if test $gl_cv_minmax_in_[]header = yes; then -AC_DEFINE([HAVE_MINMAX_IN_]HEADER, 1, +gl_CACHE_VAR, +[AC_COMPILE_IFELSE([#include <$1> + int x = MIN (42, 17);], + [gl_CACHE_VAR=yes], + [gl_CACHE_VAR=no])]) + if test $gl_CACHE_VAR = yes; then +AC_DEFINE([HAVE_MINMAX_IN_]AS_TR_CPP([$1]), 1, [Define to 1 if <$1> defines the MIN and MAX macros.]) fi - undefine([HEADER]) - undefine([header]) + m4_popdef([gl_CACHE_VAR]) ]) ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
[bug-gnulib] Re: gcc -Wall warning for minmax.h
Hello, On Fri, Jun 03, 2005 at 05:53:00PM +0200, Bruno Haible wrote: > AS_TR_* are not documented in the autoconf manual You are right. I have to start by documenting AS_TR_SH, AS_TR_CPP, AS_LITERAL_IF and m4_fatal. Then I can resubmit the patch. > AC_TRY_COMPILE is shorter and more mnemonic than the *_IFELSE macros. I believe there were good reasons why it was obsoleted. (Double quotes its param, and we cannot change the behaviour without renaming it.) If people continue to use it, they can experience unwanted surprises. If you use obsolete macros in your code, users will follow you. Please help spreading the message and avoid using it. > > - use m4_pushdef/m4_popdef instead of define/undefine This change was important. Your macro does m4_undefine([header]) and m4_undefine([HEADER]). What if these symboles were already defined? (Perhaps by another macro, written in a similar style.) An updated patch attached. Stepan 2005-06-04 Stepan Kasal <[EMAIL PROTECTED]> * minmax.m4 (gl_MINMAX_IN_HEADER): Don't use obsolete AC_TRY_COMPILE; use m4_pushdef/m4_popdef. Index: m4/minmax.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/minmax.m4,v retrieving revision 1.1 diff -u -r1.1 minmax.m4 --- m4/minmax.m423 May 2005 10:25:53 - 1.1 +++ m4/minmax.m44 Jun 2005 06:43:55 - @@ -19,20 +19,20 @@ dnl gl_MINMAX_IN_HEADER(HEADER) AC_DEFUN([gl_MINMAX_IN_HEADER], [ - define([header],[translit([$1],[./-], - [___])]) - define([HEADER],[translit([$1],[abcdefghijklmnopqrstuvwxyz./-], - [ABCDEFGHIJKLMNOPQRSTUVWXYZ___])]) + AC_PREREQ(2.50) + m4_pushdef([gl_CACHE_VAR], gl_cv_minmax_in_[]translit([$1], [./-], [___])) + m4_pushdef([HEADER],[translit([$1],[abcdefghijklmnopqrstuvwxyz./-], + [ABCDEFGHIJKLMNOPQRSTUVWXYZ___])]) AC_CACHE_CHECK([whether <$1> defines MIN and MAX], -[gl_cv_minmax_in_]header, -[AC_TRY_COMPILE([#include <$1> -int x = MIN (42, 17);], [], - [gl_cv_minmax_in_]header[=yes], - [gl_cv_minmax_in_]header[=no])]) - if test $gl_cv_minmax_in_[]header = yes; then +gl_CACHE_VAR, +[AC_COMPILE_IFELSE([#include <$1> + int x = MIN (42, 17);], + [gl_CACHE_VAR=yes], + [gl_CACHE_VAR=no])]) + if test $gl_CACHE_VAR = yes; then AC_DEFINE([HAVE_MINMAX_IN_]HEADER, 1, [Define to 1 if <$1> defines the MIN and MAX macros.]) fi - undefine([HEADER]) - undefine([header]) + m4_popdef([HEADER]) + m4_popdef([gl_CACHE_VAR]) ]) ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] [ADMIN] the bug-gnulib prefix
Hello, it's almost three months ago since I proposed to switch off the mailman feature which automatically adds the prefix "[bug-gnulib] " to each post. I asked for opinions; 3 members were for the proposal, 2 against. So I'll switch the feature off this Monday, Jun 6. I apologize that I haven't got to it earlier. Let me remind you that if you want to filter the postings to a separate folder, and if you use procmail, you can use the following recipe: :0: * ^List-Post:[EMAIL PROTECTED]> bug-gnulib-new Have a nice day, Stepan Kasal ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: gcc -Wall warning for minmax.h
Hello Derek, thank you very much for taking care about this. On Mon, Jun 06, 2005 at 02:31:24PM -0400, Derek Price wrote: > Yes, AS_TR_SH & AS_TR_CPP appear to be undocumented. I've submitted a > patch to autoconf-patches to remedy this and will commit it within a few > days unless there are objections there. I haven't seen the patch; and won't see before you commit, as I'll be offline until Jun 21. That's why I add some comments now, though you probably know most of them: - We need to document also AS_LITERAL_IF and m4_fatal (And you could also document m4_warning, when you are at it.) - we have to document also the fact that AS_TR_SH & AS_TR_CPP expand to literal variable (symbol) name, if their argument is a literal A cheeky closing note: Bruno, your code also uses undocumented macros: `define', `undefine' and `translit'. Please note that the manual states that they are _moved_ into the m4_ pseudo-namespace. And IMHO these will never be documented, they are only for backward compatibility. ;-) Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: gcc -Wall warning for minmax.h
Hi,
On Tue, Jun 07, 2005 at 10:19:47AM -0400, Derek Price wrote:
> >- we have to document also the fact that AS_TR_SH & AS_TR_CPP expand
> > to literal variable (symbol) name, if their argument is a literal
>
> I didn't think this was important from the user's perspective.
In the patch I proposed, I used gl_CACHE_VAR as the second argument
of AC_CACHE_CHECK.
That argument cannot contain backticks, see the Appendix below.
That explains why I relied on the feature, and why I wanted to document it.
But yes, it's better to fix AC_CACHE_CHECK to remove this limitation.
After that fix, we could also remove the AS_LITERAL_IF with m4_fatal.
I'm happy that AS_LITERAL_IF will stay undocumented.
m4_fatal and m4_warning should be documented, though.
Have a nice day,
Stepan
Appendix:
If gl_CACHE_VAR expanded to
`echo "xyz-xyz" | sed ...`
then you get something like:
eval "test \"\${gl_CACHE_VAR+set}\" = set"
eval "test \"\${`echo "xyz-xyz" | sed ...`+set}\" = set"
And this construct is not portable, see the first paragraph of node
"Shell Substitutions".
This can be fixed: AS_VAR_TEST_SET could in this case expand to
as_var=`echo "xyz-xyz" | sed ...`
eval "test \"\${$as_var+set}\" = set"
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: an archive of POSIX compat files ?
Hello,
On Mon, Jun 27, 2005 at 02:08:07PM +0200, Stepan Kasal wrote:
> On Thu, Jun 23, 2005 at 10:20:33PM +0200, Patrice Dumas wrote:
> > > gnulib is an existing centralised repository, with implementations
> > > under various licenses, but mostly they are GPL or LGPL.
> >
> > Maybe there could be a note about that in the autoconf manual ?
>
> standards.texi, which is distributed with Autoconf, mentiones it.
>
> But perhaps there could be a direct link from Autoconf manual; could you
> propose some wording?
I have received a proposal from Patrice. A slightly modified version is
attached below. Could any of the native speakers look at it?
Stepan
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.918
diff -u -r1.918 autoconf.texi
--- doc/autoconf.texi 24 Jun 2005 00:54:01 - 1.918
+++ doc/autoconf.texi 28 Jun 2005 10:17:55 -
@@ -4564,6 +4564,13 @@
environment. Some functions may be missing or unfixable, and your
package must be ready to replace them.
+In case you want to use already existing files, you can have a look at
[EMAIL PROTECTED]://www.gnu.org/software/gnulib/, Gnulib}, a centralized
+repository with such portability files.
+The source files are available online
+at @uref{http://savannah.gnu.org/cgi-bin/viewcvs/gnulib/gnulib/lib/}
+under various licences, mostly GNU GPL or GNU LGPL.
+
@defmac AC_LIBOBJ (@var{function})
@acindex{LIBOBJ}
@ovindex LIBOBJS
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: an archive of POSIX compat files ?
Hello,
On Tue, Jun 28, 2005 at 09:12:32AM -0400, Karl Berry wrote:
> The English seems fine to me, but since Gnulib has a Texinfo manual, it
> seems like it might make sense to use a multi-argument xref instead of
> @uref (with rewording), as in:
> @xref{Top,,,gnulib,Gnulib},
OTOH, is seems more useful to point developers to the web page than to
the info manual, which is not installed on most distributions.
Thus I think there should be both references.
What about the following variation of Keith's patch?
Stepan
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.919
diff -u -r1.919 autoconf.texi
--- doc/autoconf.texi 28 Jun 2005 13:08:29 - 1.919
+++ doc/autoconf.texi 29 Jun 2005 05:18:55 -
@@ -4564,6 +4564,14 @@
environment. Some functions may be missing or unfixable, and your
package must be ready to replace them.
+Suitable replacements for many such problem functions are available
+from @uref{http://www.gnu.org/software/gnulib/, Gnulib}, which aims
+to provide a centralized repository of such portability functions.
[EMAIL PROTECTED],,,gnulib,Gnulib}.
+The source files themselves are available online,
+under various licences, mostly GNU GPL or GNU LGPL, at
[EMAIL PROTECTED]://savannah.gnu.org/cgi-bin/viewcvs/gnulib/gnulib/lib/}.
+
@defmac AC_LIBOBJ (@var{function})
@acindex{LIBOBJ}
@ovindex LIBOBJS
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
update minmax.m4
Hello Bruno.
I think it's time to re-submit my patch to minmax.m4.
A new version of the patch is attached to this mail.
Again, it features:
> - use m4_pushdef/m4_popdef instead of define/undefine
As I explained before, you cannot inadvertently undefine([HEADER]).
> - avoid the obsoleted AC_TRY_COMPILE
Some people run "autoconf -W obsolete", and the macros from gnulib
shouldn't spoil it.
> - use AS_TR_* instead of raw m4_translit
Do you see any problem with this patch? All used macros are now documented.
Have a nice day,
Stepan
2005-06-30 Stepan Kasal <[EMAIL PROTECTED]>
* minmax.m4 (gl_MINMAX_IN_HEADER): Use m4_pushdef/m4_popdef.
Also use more modern macros.
Index: m4/minmax.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/minmax.m4,v
retrieving revision 1.1
diff -u -r1.1 minmax.m4
--- m4/minmax.m423 May 2005 10:25:53 - 1.1
+++ m4/minmax.m430 Jun 2005 16:36:01 -
@@ -17,22 +17,21 @@
])
dnl gl_MINMAX_IN_HEADER(HEADER)
+dnl The parameter has to be a literal header name; it cannot be macro,
+dnl nor a shell variable.
AC_DEFUN([gl_MINMAX_IN_HEADER],
[
- define([header],[translit([$1],[./-],
- [___])])
- define([HEADER],[translit([$1],[abcdefghijklmnopqrstuvwxyz./-],
- [ABCDEFGHIJKLMNOPQRSTUVWXYZ___])])
+ AC_PREREQ(2.50)
+ m4_pushdef([gl_CACHE_VAR], gl_cv_minmax_in_[]AS_TR_SH([$1]))
AC_CACHE_CHECK([whether <$1> defines MIN and MAX],
-[gl_cv_minmax_in_]header,
-[AC_TRY_COMPILE([#include <$1>
-int x = MIN (42, 17);], [],
- [gl_cv_minmax_in_]header[=yes],
- [gl_cv_minmax_in_]header[=no])])
- if test $gl_cv_minmax_in_[]header = yes; then
-AC_DEFINE([HAVE_MINMAX_IN_]HEADER, 1,
+gl_CACHE_VAR,
+[AC_COMPILE_IFELSE([#include <$1>
+ int x = MIN (42, 17);],
+ [gl_CACHE_VAR=yes],
+ [gl_CACHE_VAR=no])])
+ if test $gl_CACHE_VAR = yes; then
+AC_DEFINE([HAVE_MINMAX_IN_]AS_TR_CPP([$1]), 1,
[Define to 1 if <$1> defines the MIN and MAX macros.])
fi
- undefine([HEADER])
- undefine([header])
+ m4_popdef([gl_CACHE_VAR])
])
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: an archive of POSIX compat files ?
Hi,
I committed the patch attached to this mail.
Stepan
2005-06-30 Stepan Kasal <[EMAIL PROTECTED]>
* doc/autoconf.texi (Generic Functions): Mention the Gnulib project.
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.921
diff -u -r1.921 autoconf.texi
--- doc/autoconf.texi 29 Jun 2005 10:47:38 - 1.921
+++ doc/autoconf.texi 30 Jun 2005 12:29:04 -
@@ -4564,6 +4564,12 @@
environment. Some functions may be missing or unfixable, and your
package must be ready to replace them.
+Suitable replacements for many such problem functions are available from
[EMAIL PROTECTED]://www.gnu.org/software/gnulib/, Gnulib}, which aims to
+provide a centralized repository of such portability functions (among
+other things). The source files are available online, under various
+licences, mostly GNU GPL or GNU LGPL.
+
@defmac AC_LIBOBJ (@var{function})
@acindex{LIBOBJ}
@ovindex LIBOBJS
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: mbrtowc.m4 on mingw32
Hello Bruno, On Mon, Jul 04, 2005 at 01:18:25PM +0200, Bruno Haible wrote: > On mingw32, mbrtowc.m4 "detects" that mbrtowc() exists, leading to > link errors. Actually, mbrtowc() does not exist on this system, > it's only declared in but not actually implemented under > this name. why cannot we use the Autoconf macro AC_FUNC_MBRTOWC? (I mean with current Autoconf. If there is a need to support some older versions of Autoconf, we could perhaps copy the definition of the macro to gnulib's mbrtowc.m4.) A copy of the macro is attached below; does it work for you? Have a nice day, Stepan # AC_FUNC_MBRTOWC # --- AN_FUNCTION([mbrtowc], [AC_FUNC_MBRTOWC]) AC_DEFUN([AC_FUNC_MBRTOWC], [ AC_CACHE_CHECK([whether mbrtowc and mbstate_t are properly declared], ac_cv_func_mbrtowc, [AC_LINK_IFELSE( [AC_LANG_PROGRAM( [EMAIL PROTECTED]:@include ]], [[wchar_t wc; char const s[] = ""; size_t n = 1; mbstate_t state; return ! (sizeof state && (mbrtowc) (&wc, s, n, &state));]])], ac_cv_func_mbrtowc=yes, ac_cv_func_mbrtowc=no)]) if test $ac_cv_func_mbrtowc = yes; then AC_DEFINE([HAVE_MBRTOWC], 1, [Define to 1 if mbrtowc and mbstate_t are properly declared.]) fi ]) ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: check-module
Hello,
On Mon, Jul 11, 2005 at 01:30:32PM +0200, Bruno Haible wrote:
> > (cd modules; ../check-module *)
...
> There seems to be a portability problem with the check-module script:
actually, the script didn't seem to be prepared for such usage at all.
It seems that the script actually checked only the first module.
I tried to enhance the script to do what we expect.
The patch, merged with Bruno's previous patch, is attached to this mail.
Have a nice day,
Stepan Kasal
2005-07-11 Bruno Haible <[EMAIL PROTECTED]>
and Stepan Kasal <[EMAIL PROTECTED]>
* check-module: If more parameters are given, check each of them
separately; add more exceptions, as noted by Jim Meyering.
(check_module): New procedure.
(%exempt_header): Now contains all exceptions.
Index: check-module
===
RCS file: /cvsroot/gnulib/gnulib/check-module,v
retrieving revision 1.2
diff -u -r1.2 check-module
--- check-module28 Jun 2005 11:55:41 - 1.2
+++ check-module11 Jul 2005 12:34:07 -
@@ -144,17 +144,6 @@
exists $inc{$line} && ! exists $special_non_dup{$line}
and warn "$ME: $file: duplicate inclusion of $line\n";
- # Some known exceptions.
- $file =~ /\bfull-write\.c$/ && $line eq 'full-read.h'
- and next;
- $file =~ /\bsafe-read.c$/ && $line eq 'safe-write.h'
- and next;
- $file =~ /\bhash\.c$/ && $line eq 'obstack.h'
- and next;
- $file =~ /\bfts\.c$/ &&
- ($line eq 'fts-cycle.c' || $line eq 'unistd-safer.h')
- and next;
-
$inc{$line} = 1;
}
close FH;
@@ -162,23 +151,40 @@
return \%inc;
}
-{
- GetOptions
-(
- help => sub { usage 0 },
- version => sub { print "$ME version $VERSION\n"; exit },
-) or usage 1;
+my %exempt_header =
+ (
+ # Exempt headers like unlocked-io.h that are `#include'd
+ # but not necessarily used.
+ 'unlocked-io.h' => 1,
+
+ # Give gettext.h a free pass only when included from lib/error.c,
+ # since we've made that exception solely to make the error
+ # module easier to use -- at RMS's request.
+ 'lib/error.c:gettext.h' => 1,
+
+ # The full-read module shares code with the full-write module.
+ 'lib/full-write.c:full-read.h' => 1,
+
+ # The safe-write module shares code with the safe-read module.
+ 'lib/safe-read.c:safe-write.h' => 1,
+
+ # The use of obstack.h in the hash module is conditional, off by default.
+ 'lib/hash.c:obstack.h' => 1,
+
+ # The fts-lgpl module doesn't actually use fts-cycle.c and unistd-safer.h.
+ 'lib/fts.c:fts-cycle.c' => 1,
+ 'lib/fts.c:unistd-safer.h' => 1,
+ );
- @ARGV < 1
-and (warn "$ME: missing FILE argument\n"), usage 1;
+sub check_module ($)
+{
+ my @m = @_;
my %file;
my %module_all_files;
my %dep;
my %seen_module;
- my @m = $ARGV[0];
-
while (@m)
{
my $m = pop @m;
@@ -194,18 +200,6 @@
}
}
- my %exempt_header =
-(
- # Exempt headers like unlocked-io.h that are `#include'd
- # but not necessarily used.
- 'unlocked-io.h' => 1,
-
- # Give gettext.h a free pass only when included from lib/error.c,
- # since we've made that exception solely to make the error
- # module easier to use -- at RMS's request.
- 'lib/error.c:gettext.h' => 1,
-);
-
my @t = sort keys %module_all_files;
# warn "ALL files: @t\n";
@@ -229,6 +223,22 @@
}
#my @t = sort keys %$inc;
#print "** $f: @t\n";
+}
+}
+
+{
+ GetOptions
+(
+ help => sub { usage 0 },
+ version => sub { print "$ME version $VERSION\n"; exit },
+) or usage 1;
+
+ @ARGV < 1
+and (warn "$ME: missing FILE argument\n"), usage 1;
+
+ foreach my $module (@ARGV)
+{
+ check_module $module;
}
exit 0;
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: new module gettext-h for programs that don't use i18n
Hello Bruno, > for this is the --avoid option to gnulib-tool, which I've now implemented. Great! Thank you very much for this long awaited option. Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: lgpl compatible files archive?
Hello, On Mon, Jul 04, 2005 at 11:46:41AM -0700, Paul Eggert wrote: > I would say the one exception is getcwd, where the code to support > arbitrarily-deep nesting is not LGPLed anywhere that I can see. does this mean that the arbitrarily-deep nesting code is not going to be contributed back to glibc? (If the code were eventually LGPLed via glibc, I'd see no reason why should anyone spend some time creating getcwd-lgpl.) Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: Opening a can of worms: a readline gnulib module?
Hello, On Sat, Jul 16, 2005 at 10:53:45AM +0200, Simon Josefsson wrote: > All of this is hypothetical though, since it doesn't look like adding > the readline library as a gnulib module will happen now. Why not? I don't see any reason against the "readline stub" module you proposed. Bruno pointed out problems with "full readline" module, and asked: > > rl_add_defun etc.). Do you want to provide all these symbols? Your answer was no. So with your module, the application would have: 1) readline() function 2) #if READLINE I guess it might be worth it. Opinions? Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
patch ping: check-module
Hello,
about two weeks ago I submitted a patch
http://lists.gnu.org/archive/html/bug-gnulib/2005-07/msg00084.html
I verified that the archive hasn't clobbered it, except the first
two lines:
2005-07-11 Bruno Haible <[EMAIL PROTECTED]>
and Stepan Kasal <[EMAIL PROTECTED]>
Could any of the readers find time to look at it?
[Or could I get access to gnulib CVS, so that I can commit it myself?]
Have a nice day,
Stepan
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: error: possibly undefined macro: AC_CHECK_HEADERS_ONCE
Hello, On Sun, Aug 07, 2005 at 01:21:04PM -0400, Sam Steingold wrote: > > Maybe this trick is not working reliably; aclocal was not designed for > > this... Could you post the ad hoc created configure.in? so it seems the problem is in regex.m4, which comes from gnulib. Thus I cc this post to bug-gnulib. The macro gl_INCLUDED_REGEX contains this: m4_syscmd([test -f '$1']) ifelse(m4_sysval, 0, [ ... gl_PREREQ_REGEX ]) Macro gl_PREREQ_REGEX, which calls AC_CHECK_HEADERS_ONCE, is expanded only if the current directory contains the file "regex.c" (the argument to gl_INCLUDED_REGEX). For Sam: so the magic workaround should be to touch the file "regex.c" in the same directory where you have your artificial configure.in. For gnulib people: Why is the above trick necessary? Why should the macro expansion depend on the presence of the file? Second: just above the quoted code: test -n "$1" || AC_MSG_ERROR([missing argument]) yes, the macro gl_INCLUDED_REGEX requires a parameter, but why it should be reported in runtime? (Yes, the parameter might be a shell variable, but is this done often?) Third, the name regex.m4 conflicts with a file in Automake. This can cause problems with "aclocal --include". Could we perhaps rename it? Fourth, I noticed a typo; could you please apply the attached patch? Fifth: when my "minmax" patch is resolved (Bruno ;-), shouldn't something similar go to onceonly*.m4, too? Have a nice day, Stepan Kasal 2005-08-10 Stepan Kasal <[EMAIL PROTECTED]> * onceonly_2_57.m4: Really require Autoconf 2.57. Index: m4/onceonly_2_57.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/onceonly_2_57.m4,v retrieving revision 1.5 diff -u -r1.5 onceonly_2_57.m4 --- m4/onceonly_2_57.m4 18 Mar 2003 10:08:34 - 1.5 +++ m4/onceonly_2_57.m4 10 Aug 2005 09:02:40 - @@ -1,5 +1,5 @@ -# onceonly_2_57.m4 serial 3 -dnl Copyright (C) 2002-2003 Free Software Foundation, Inc. +# onceonly_2_57.m4 serial 4 +dnl Copyright (C) 2002-2003, 2005 Free Software Foundation, Inc. dnl This file is free software, distributed under the terms of the GNU dnl General Public License. As a special exception to the GNU General dnl Public License, this file may be distributed as part of a program @@ -27,7 +27,7 @@ dnl size reduction is ca. 9%. dnl Autoconf version 2.57 or newer is recommended. -AC_PREREQ(2.54) +AC_PREREQ(2.57) # AC_CHECK_HEADERS_ONCE(HEADER1 HEADER2 ...) is a once-only variant of # AC_CHECK_HEADERS(HEADER1 HEADER2 ...). ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: Non-standard types in public header files (was: Re: ssize_t)
Hello, this mail is a lengthy story "to the most abstract solution and back to the basic one". Sorry, I couldn't have helped. > The problem, of course, is that the installed header file cannot > assume a config.h and the HAVE_* stuff. Indeed, this is the root of the problem. You try to find a solution which works without config.h. But this means that the installed headers contain have the required bits of information in a cryptic way. I'd pull the other end of the rope. If the information from config.h is needed, we can just install config.h along with the public headers. Of course, we have to use a different name for it, like gnutls-config.h, and we probably don't want to install the whole config.h, but just part of it. There are several ways how to get the subset of config.h: 1) create a make rule which would generate the subset from config.h 2) Both headers would be generated by configure, the template for the subset would be maintained manually. Look at http://cvs.gnome.org/viewcvs/goffice/ to see this in work. 3) Both the subset and the main config.h would be generated by autoheader. First, autoheader would have to be enhanced, according to this proposal http://lists.gnu.org/archive/html/autoconf/2005-05/msg00054.html Then, you'd give "gnutls-config.h" as the fourth parameter to the AC_DEFINEs which should go there. And then you'd probably need AH_BOTTOM([#include ]) to include the subset into the main config.h. I'd prefer the last solution, but it requires a non-existent feature of autoconf > 2.59. :-) Then we get back to gnulib: how could gnulib-tool easily hook into this? With solution 3): The gnulib m4 files would contain calls like this: AC_DEFINE([PUBLIC_SYMBOL], 1, [A description]m4_ifdef([gl_FEATURE_HEADER], [, gl_FEATURE_HEADER])) As soon as would the user define macro gl_FEATURE_HEADER, the "public" symbols would go to a separate file. But does this work? How can gnulib maintainers know which defines are needed by your public headers? The maintainer of the project has to define the subset for "gnutls-config.h". So actually, it might be better to use the solution 2), with manually defined subset of config.h. But since the AC_DEFINE calls are not under your direct control, they are brought by some third party macros, there is a danger that some AC_DEFINE will disappear from configure and you won't notice it. So, after all, it seems that in your case the most robust solution might be 1). The script would not only select the #undef lines and accompanying comments, it would also check that all expected symbols were actually seen. So if an expected symbol disappered from config.h.in, the script would cry. End of my tale. Is it useful for you? Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
regex: malloc 0 bytes
Hello,
another patch for new regex module:
Stepan
- Forwarded message from Yuri Vasilevski <[EMAIL PROTECTED]> -
Date: Tue, 23 Aug 2005 23:17:40 -0500
To: [EMAIL PROTECTED]
Subject: Bug Report: sed-4.1.4 misinterprets uClibc's malloc (patch included)
Hi,
Recent versions of sed expect glibc behavior form malloc, i.e.
malloc(0) return live pointer. This is not true for uClibc (and many
other old/classical libc implementations).
So I made and attach a patch to solve this problem. It basically makes
re_node_set_alloc(set,0) behave exactly as re_node_set_init_empty(set).
Yuri.
- End forwarded message -
diff -Naur sed-4.1.4.orig/lib/regex_internal.c sed-4.1.4/lib/regex_internal.c
--- sed-4.1.4.orig/lib/regex_internal.c 2005-01-28 09:07:56 +
+++ sed-4.1.4/lib/regex_internal.c 2005-08-24 03:20:28 +
@@ -885,8 +885,9 @@
{
set->alloc = size;
set->nelem = 0;
- set->elems = re_malloc (int, size);
- if (BE (set->elems == NULL, 0))
+ set->elems = re_malloc (int, size); /* can be NULL if size == 0
+ (see re_node_set_init_empty(set)) */
+ if (BE (set->elems == NULL && size != 0, 0))
return REG_ESPACE;
return REG_NOERROR;
}
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: error: possibly undefined macro: AC_CHECK_HEADERS_ONCE
Hello, On Tue, Aug 23, 2005 at 04:41:22PM -0400, Sam Steingold wrote: > GNU CLISP comes with regex.c and it places it in the "current" > directory. > clisp/modules/regexp/configure.in > has > gl_INCLUDED_REGEX([regex.c]) > and files files > clisp/modules/regexp/regex.h > clisp/modules/regexp/regex.c > &c. and I suppose that if you do cd clisp/modules/regex; aclocal; autoconf then you get configure script, right? > note that the original problem (see the subject line) is still there. The original problem was with the artificial configure.in, which was a concatenation of all configure.in's in the tree. You ran aclocal on it, to bring all macros. With that artificial configure.in, regex.c was not in current directory, thus the part with macro AC_CHECK_HEADERS_ONCE was skipped, and thus aclocal decided not to copy it into aclocal.m4. Later on, autoconf was run in clisp/modules/regex, and it complained that the definition of AC_CHECK_HEADERS_ONCE was missing. I believe that the problem described above was fixed by Paul's patch. It might be best to start from scratch, with fresh gnulib CVS checkout. When you encounter a problem, please submit another self-contained bug report, so we can start from scratch, too. And please attach the script which you use to create the artificial configure.in, so that we can try to reproduce the bug. Sorry, but I believe this is the best possible way now. (It is possible that you get the same symptoms, though the reasons are different.) Have a nice day, Stepan Kasal ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: gnulib textual domain?
Hello, On Sat, Aug 13, 2005 at 03:20:56PM +0200, Oskar Liljeblad wrote: > For example, I was looking for translations > for lib/regcomp.c in Gnulib. Is there any project that has those > translations, or are they completely new? the regex module came from GNU libc, glibc. I guess that project is part of the Translation project. I believe that the Translation project contains one common translation pool, which should include messages from coreutils and from glibc. The translations from that memory should go smoothly to the translation of your project. Yes, there is some redundancy, but I believe it doesn't present any significant extra work for the translators. Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: error: possibly undefined macro: AC_CHECK_HEADERS_ONCE
Hello, On Wed, Aug 24, 2005 at 10:30:44PM -0400, Sam Steingold wrote: > gnulib CVS head does not contain gl_INCLUDED_REGEX. Indeed: revision 1.42 date: 2005/08/23 18:48:31; author: eggert; state: Exp; lines: +95 -109 * regex.m4 (gl_INCLUDED_REGEX): Remove; no longer used. All contents moved to gl_REGEX. (gl_REGEX): Don't bother checking whether lib/regex.c exists; assume that it does. The first change means you have to call gl_REGEX instead. The second change fixes your problem (see subj. line). > the easiest way to reproduce the problem is > $ cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/clisp login > $ cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/clisp co -P clisp > $ cd clisp > $ make -f Makefile.devel check-configures Thanks for this hint. It sounds trivial for you, but it helped me a lot. Indeed, when I cp ../gnulib/m4/regex.m4 src/m4/ and apply the patch attached below, then make -f Makefile.devel check-configures There was one remaining problem: AC_GNU_SOURCE has to be called early in configure.ac. For projects which use gnulib-tool, macro gl_EARLY takes care of this; but you have to take care of it yourself. Have a nice day, Stepan Kasal ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: error: possibly undefined macro: AC_CHECK_HEADERS_ONCE
Hello, On Thu, Aug 25, 2005 at 11:06:00AM +0200, Stepan Kasal wrote: > Indeed, when I cp ../gnulib/m4/regex.m4 src/m4/ > and apply the patch attached below, then > > make -f Makefile.devel check-configures I forgot to attach the patch, sorry. Please find it attached to this mail. Stepan Kasal Index: Makefile.devel === RCS file: /cvsroot/clisp/clisp/Makefile.devel,v retrieving revision 1.136 diff -u -r1.136 Makefile.devel --- Makefile.devel 4 Aug 2005 22:21:30 - 1.136 +++ Makefile.devel 25 Aug 2005 10:12:30 - @@ -137,10 +137,13 @@ src/autoconf/aclocal.m4 : $(wildcard src/m4/*.m4) \ $(addsuffix .in,$(CLISP_CONFIGURES)) egrep '(AC_INIT|AC_PREREQ)' src/configure.in > configure.ac - cat $(addsuffix .in,$(CLISP_CONFIGURES)) | egrep -v '(AC_INIT|AC_CONFIG_HEADER|AC_OUTPUT|AC_CONFIG_FILE.*(Makefile|link\.sh)|_CANONICAL_|AC_PREREQ)' >> configure.ac + echo AC_GNU_SOURCE >> configure.ac + cat $(addsuffix .in,$(CLISP_CONFIGURES)) | \ + egrep -v -e 'AC_(INIT|PREREQ|CANONICAL_|GNU_SOURCE|CONFIG_HEADER|OUTPUT)' \ + -e 'AC_CONFIG_FILE.*(Makefile|link\.sh)' >> configure.ac echo AC_OUTPUT >> configure.ac aclocal -I `pwd`/src/m4 --output=src/autoconf/aclocal.m4 - $(RM) configure.ac + #$(RM) configure.ac AUTOCONF_FILES = src/autoconf/aclocal.m4 AUTOCONF = autoconf Index: modules/regexp/configure.in === RCS file: /cvsroot/clisp/clisp/modules/regexp/configure.in,v retrieving revision 1.15 diff -u -r1.15 configure.in --- modules/regexp/configure.in 4 Aug 2005 22:10:53 - 1.15 +++ modules/regexp/configure.in 25 Aug 2005 10:12:30 - @@ -4,6 +4,7 @@ AC_PREREQ(2.57) AC_INIT(regexp, 1.0, clisp-list) +AC_GNU_SOURCE AC_CONFIG_SRCDIR(regexp.lisp) AC_CONFIG_AUX_DIR(../../src/build-aux) AC_CONFIG_HEADERS(config.h) @@ -16,7 +17,7 @@ AM_GNU_GETTEXT([external]) gl_C_RESTRICT gl_FUNC_ALLOCA -gl_INCLUDED_REGEX([regex.c]) +gl_REGEX # can we use the system-wide regex implementation? if test "$ac_use_included_regex" = no -a "$cl_cv_regexp" = yes; then ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
regex.m4: skip autodetection if it is not necessary
Hello, would you accept this patch? Stepan Kasal 2005-08-25 Stepan Kasal <[EMAIL PROTECTED]> * regex.m4: If --with-included-regex was given, skip the autodetection. Index: m4/regex.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/regex.m4,v retrieving revision 1.43 diff -u -r1.43 regex.m4 --- m4/regex.m4 24 Aug 2005 23:29:39 - 1.43 +++ m4/regex.m4 25 Aug 2005 12:04:40 - @@ -1,4 +1,4 @@ -#serial 27 +#serial 28 # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005 Free # Software Foundation, Inc. @@ -10,27 +10,33 @@ dnl Initially derived from code in GNU grep. dnl Mostly written by Jim Meyering. +AC_PREREQ([2.50]) + AC_DEFUN([gl_REGEX], [ AC_LIBSOURCES( [regcomp.c, regex.c, regex.h, regex_internal.c, regex_internal.h, regexec.c]) - dnl Even packages that don't use regex.c can use this macro. - dnl Of course, for them it doesn't do anything. - - # Assume we'll default to using the included regex.c. - ac_use_included_regex=yes - - # However, if the system regex support is good enough that it passes the - # the following run test, then default to *not* using the included regex.c. - # If cross compiling, assume the test would fail and use the included - # regex.c. The first failing regular expression is from `Spencer ere - # test #75' in grep-2.3. - AC_CACHE_CHECK([for working re_compile_pattern], -[gl_cv_func_working_re_compile_pattern], -[AC_RUN_IFELSE( - [AC_LANG_PROGRAM( + AC_ARG_WITH([included-regex], +[AC_HELP_STRING([--without-included-regex], + [don't compile regex; this is the default on +systems with recent-enough versions of the GNU C +Library (use with caution on other systems)])]) + + case $with_included_regex in + yes|no) ac_use_included_regex=$with_included_regex + ;; + '') +# If the system regex support is good enough that it passes the the +# following run test, then default to *not* using the included regex.c. +# If cross compiling, assume the test would fail and use the included +# regex.c. The first failing regular expression is from `Spencer ere +# test #75' in grep-2.3. +AC_CACHE_CHECK([for working re_compile_pattern], + [gl_cv_func_re_compile_pattern_broken], + [AC_RUN_IFELSE( + [AC_LANG_PROGRAM( [AC_INCLUDES_DEFAULT #include ], [[static struct re_pattern_buffer regex; @@ -92,21 +98,17 @@ exit (1); exit (0);]])], - [gl_cv_func_working_re_compile_pattern=yes], - [gl_cv_func_working_re_compile_pattern=no], + [gl_cv_func_re_compile_pattern_broken=no], + [gl_cv_func_re_compile_pattern_broken=yes], dnl When crosscompiling, assume it is broken. - [gl_cv_func_working_re_compile_pattern=no])]) - if test $gl_cv_func_working_re_compile_pattern = yes; then -ac_use_included_regex=no - fi + [gl_cv_func_re_compile_pattern_broken=yes])]) +ac_use_included_regex=$gl_cv_func_re_compile_pattern_broken +;; + *) AC_MSG_ERROR([Invalid value for --with-included-regex: $with_included_regex]) +;; + esac - AC_ARG_WITH([included-regex], -[ --without-included-regex don't compile regex; this is the default on - systems with recent-enough versions of the GNU C - Library (use with caution on other systems)], -[gl_with_regex=$withval], -[gl_with_regex=$ac_use_included_regex]) - if test "X$gl_with_regex" = Xyes; then + if test $ac_use_included_regex = yes; then AC_LIBOBJ([regex]) gl_PREREQ_REGEX fi ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: sysexits.h: Define EX_OK
Hello, On Wed, Aug 24, 2005 at 10:20:08PM -0700, Paul Eggert wrote: > Let's please just define [EX_OK] to 0; [...] > > I also like Simon's suggestion of defining EXIT_SUCCESS and > EXIT_FAILURE in config.h, [...] something like the attached patch (not tested)? Stepan diff -urpN gnulib/lib/.cppi-disable gnulib.new/lib/.cppi-disable --- gnulib/lib/.cppi-disable2005-08-25 14:51:21.0 +0200 +++ gnulib.new/lib/.cppi-disable2005-08-25 14:52:42.0 +0200 @@ -1,7 +1,6 @@ alloca_.h allocsa.h error.h -exit.h fnmatch_.h fts.c fts_.h diff -urpN gnulib/lib/argmatch.c gnulib.new/lib/argmatch.c --- gnulib/lib/argmatch.c 2005-08-25 14:51:21.0 +0200 +++ gnulib.new/lib/argmatch.c 2005-08-25 14:52:42.0 +0200 @@ -36,7 +36,7 @@ #define _(msgid) gettext (msgid) #include "error.h" -#include "exit.h" +#include #include "quotearg.h" #include "quote.h" diff -urpN gnulib/lib/copy-file.c gnulib.new/lib/copy-file.c --- gnulib/lib/copy-file.c 2005-08-25 14:51:21.0 +0200 +++ gnulib.new/lib/copy-file.c 2005-08-25 14:52:42.0 +0200 @@ -45,7 +45,7 @@ #include "safe-read.h" #include "full-write.h" #include "binary-io.h" -#include "exit.h" +#include #include "gettext.h" #define _(str) gettext (str) diff -urpN gnulib/lib/execute.c gnulib.new/lib/execute.c --- gnulib/lib/execute.c2005-08-25 14:51:21.0 +0200 +++ gnulib.new/lib/execute.c2005-08-25 14:52:42.0 +0200 @@ -35,7 +35,7 @@ #endif #include "error.h" -#include "exit.h" +#include #include "fatal-signal.h" #include "wait-process.h" #include "gettext.h" diff -urpN gnulib/lib/exit.h gnulib.new/lib/exit.h --- gnulib/lib/exit.h 2005-08-25 14:51:33.0 +0200 +++ gnulib.new/lib/exit.h 1970-01-01 01:00:00.0 +0100 @@ -1,32 +0,0 @@ -/* exit() function. - Copyright (C) 1995, 2001 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. */ - -#ifndef _EXIT_H -#define _EXIT_H - -/* Get exit() declaration. */ -#include - -/* Some systems do not define EXIT_*, even with STDC_HEADERS. */ -#ifndef EXIT_SUCCESS -# define EXIT_SUCCESS 0 -#endif -#ifndef EXIT_FAILURE -# define EXIT_FAILURE 1 -#endif - -#endif /* _EXIT_H */ diff -urpN gnulib/lib/exitfail.c gnulib.new/lib/exitfail.c --- gnulib/lib/exitfail.c 2005-08-25 14:51:21.0 +0200 +++ gnulib.new/lib/exitfail.c 2005-08-25 14:52:42.0 +0200 @@ -22,6 +22,6 @@ #endif #include "exitfail.h" -#include "exit.h" +#include int volatile exit_failure = EXIT_FAILURE; diff -urpN gnulib/lib/pagealign_alloc.c gnulib.new/lib/pagealign_alloc.c --- gnulib/lib/pagealign_alloc.c2005-08-25 14:51:21.0 +0200 +++ gnulib.new/lib/pagealign_alloc.c2005-08-25 14:52:42.0 +0200 @@ -39,7 +39,7 @@ #endif #include "error.h" -#include "exit.h" +#include #include "getpagesize.h" #include "xalloc.h" #include "gettext.h" diff -urpN gnulib/lib/pipe.c gnulib.new/lib/pipe.c --- gnulib/lib/pipe.c 2005-08-25 14:51:21.0 +0200 +++ gnulib.new/lib/pipe.c 2005-08-25 14:52:42.0 +0200 @@ -34,7 +34,7 @@ #endif #include "error.h" -#include "exit.h" +#include #include "fatal-signal.h" #include "wait-process.h" #include "gettext.h" diff -urpN gnulib/lib/sysexit_.h gnulib.new/lib/sysexit_.h --- gnulib/lib/sysexit_.h 2005-08-25 14:51:21.0 +0200 +++ gnulib.new/lib/sysexit_.h 2005-08-25 14:52:42.0 +0200 @@ -1,5 +1,5 @@ /* exit() exit codes for some BSD system programs. - Copyright (C) 2003 Free Software Foundation, Inc. + Copyright (C) 2003, 2005 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 @@ -20,6 +20,7 @@ #ifndef _SYSEXITS_H #define _SYSEXITS_H +#define EX_OK 0 #define EX_USAGE 64 #define EX_DATAERR 65 #define EX_NOINPUT 66 diff -urpN gnulib/lib/wait-process.c gnulib.new/lib/wait-process.c --- gnulib/lib/wait-process.c 2005-08-25 14:51:21.0 +0200 +++ gnulib.new/lib/wait-process.c 2005-08-25 14:52:42.0 +0200 @@ -91,7 +91,7 @@ #endif #include "error.h" -#include "exit.h" +#include #include "fatal-signal.h" #include "xalloc.h" #include "gettext.h" diff -urpN gnulib/lib/xsetenv.c gnuli
Re: [bug-gnulib] synced mktime.c and strtol.c from intprops.h
Hello, regarding this old patch: On Mon, Mar 14, 2005 at 04:46:10PM -0800, Paul Eggert wrote: > When I updated intprops.h I forgot to make similar modifications to > mktime.c and strtol.c. I installed this patch to fix that. > > 2005-03-14 Paul Eggert <[EMAIL PROTECTED]> > > * mktime.c (TYPE_TWOS_COMPLEMENT, TYPE_ONES_COMPLEMENT, > TYPE_SIGNED_MAGNITUDE, TYPE_MINIMUM, TYPE_MAXIMUM): Sync from > intprops.h. > * strtol.c: Likewise. Why it is not possible to #include intprops.h? What would be wrong with the following patch? Stepan 2005-08-25 Stepan Kasal <[EMAIL PROTECTED]> * modules/mktime, modules/strtol: Add lib/intprops.h. * modules/xstrtol: Fix a typo in a comment. 2005-08-25 Stepan Kasal <[EMAIL PROTECTED]> * mktime.c, strtol.c: Include intprops.h instead of defining the same macros. Index: lib/mktime.c === RCS file: /cvsroot/gnulib/gnulib/lib/mktime.c,v retrieving revision 1.52 diff -u -r1.52 mktime.c --- lib/mktime.c23 Jun 2005 07:14:09 - 1.52 +++ lib/mktime.c25 Aug 2005 14:28:49 - @@ -62,38 +62,7 @@ ? (a) >> (b)\ : (a) / (1 << (b)) - ((a) % (1 << (b)) < 0)) -/* The extra casts in the following macros work around compiler bugs, - e.g., in Cray C 5.0.3.0. */ - -/* True if the arithmetic type T is an integer type. bool counts as - an integer. */ -#define TYPE_IS_INTEGER(t) ((t) 1.5 == 1) - -/* True if negative values of the signed integer type T use two's - complement, ones' complement, or signed magnitude representation, - respectively. Much GNU code assumes two's complement, but some - people like to be portable to all possible C hosts. */ -#define TYPE_TWOS_COMPLEMENT(t) ((t) ~ (t) 0 == (t) -1) -#define TYPE_ONES_COMPLEMENT(t) ((t) ~ (t) 0 == 0) -#define TYPE_SIGNED_MAGNITUDE(t) ((t) ~ (t) 0 < (t) -1) - -/* True if the arithmetic type T is signed. */ -#define TYPE_SIGNED(t) (! ((t) 0 < (t) -1)) - -/* The maximum and minimum values for the integer type T. These - macros have undefined behavior if T is signed and has padding bits. - If this is a problem for you, please let us know how to fix it for - your host. */ -#define TYPE_MINIMUM(t) \ - ((t) (! TYPE_SIGNED (t) \ - ? (t) 0 \ - : TYPE_SIGNED_MAGNITUDE (t) \ - ? ~ (t) 0 \ - : ~ (t) 0 << (sizeof (t) * CHAR_BIT - 1))) -#define TYPE_MAXIMUM(t) \ - ((t) (! TYPE_SIGNED (t) \ - ? (t) -1 \ - : ~ (~ (t) 0 << (sizeof (t) * CHAR_BIT - 1 +#include "intprops.h" #ifndef TIME_T_MIN # define TIME_T_MIN TYPE_MINIMUM (time_t) Index: lib/strtol.c === RCS file: /cvsroot/gnulib/gnulib/lib/strtol.c,v retrieving revision 1.23 diff -u -r1.23 strtol.c --- lib/strtol.c14 May 2005 06:03:58 - 1.23 +++ lib/strtol.c25 Aug 2005 14:28:49 - @@ -124,34 +124,7 @@ # define STRTOL_LONG_MAX LONG_LONG_MAX # define STRTOL_ULONG_MAX ULONG_LONG_MAX -/* The extra casts in the following macros work around compiler bugs, - e.g., in Cray C 5.0.3.0. */ - -/* True if negative values of the signed integer type T use two's - complement, ones' complement, or signed magnitude representation, - respectively. Much GNU code assumes two's complement, but some - people like to be portable to all possible C hosts. */ -# define TYPE_TWOS_COMPLEMENT(t) ((t) ~ (t) 0 == (t) -1) -# define TYPE_ONES_COMPLEMENT(t) ((t) ~ (t) 0 == 0) -# define TYPE_SIGNED_MAGNITUDE(t) ((t) ~ (t) 0 < (t) -1) - -/* True if the arithmetic type T is signed. */ -# define TYPE_SIGNED(t) (! ((t) 0 < (t) -1)) - -/* The maximum and minimum values for the integer type T. These - macros have undefined behavior if T is signed and has padding bits. - If this is a problem for you, please let us know how to fix it for - your host. */ -# define TYPE_MINIMUM(t) \ - ((t) (! TYPE_SIGNED (t) \ -? (t) 0 \ -: TYPE_SIGNED_MAGNITUDE (t) \ -? ~ (t) 0 \ -: ~ (t) 0 << (sizeof (t) * CHAR_BIT - 1))) -# define TYPE_MAXIMUM(t) \ - ((t) (! TYPE_SIGNED (t) \ -? (t) -1 \ -: ~ (~ (t) 0 << (sizeof (t) * CHAR_BIT - 1 +# include "intprops.h" # ifndef ULONG_LONG_MAX # define ULONG_LONG_MAX TYPE_MAXIMUM (unsigned long long) Index: modules/mktime === RCS file: /cvsroot/gnulib/gnulib/modules/mktime,v retrieving revision 1.5 diff -u -r1.5 mktime --- modules/mktime 22 Sep 2004 15:11:04 - 1.5 +++ modules/mktime 25 Aug 2005 14:28:49 - @@ -2,6 +2,7 @@ mktime() function: convert broken-down time to linear time. Files: +lib/intprops.h lib/mktime.c m4/mktime.m4 Index: modules/strtol ==
Re: error: possibly undefined macro: AC_CHECK_HEADERS_ONCE
Hello, On Thu, Aug 25, 2005 at 09:36:12AM -0400, Sam Steingold wrote: > But I do not have lib/regex.c! > I have regex.c in the current directory! > Is it OK? yes, it is. Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: Non-standard types in public header files
Hello, On Sat, Aug 13, 2005 at 07:30:21PM -0500, Albert Chin wrote: > Look at how glib solves a similar problem. Of course, they define > their own types but they install a platform-specific .h file in > $prefix/lib/include (glibconfig.h). This is similar to the > gnutls-config.h suggested by Stepan Kasal. > > AC_CONFIG_COMMANDS([gnutlsconfig.h], > [ > outfile=gnutlsconfig.h > cat >$outfile <<_EOF_ > #ifndef __GNUTLSCONFIG_H__ > #define __GNUTLSCONFIG_H__ > > _EOF_ > > if test x$HAVE_SSIZE_T = xyes; then > echo '#define GTLS_SSIZE_T ssize_t' >>$outfile > else > echo '#define GTLS_SSIZE_T long' >>$outfile > fi > > echo '#endif /* __GNUTLSCONFIG_H__ */' >>$outfile > ]) yes, this is similar, but not pure enough, I think. I think that gnutlsconfig.h should contain only information bits about the system, with comments similar to what you see in config.h. So it would #define GNUTLS_HAVE_SSIZE_T or not. Currently, glib's configure.in contains: outfile=glibconfig.h-tmp if test x$glib_limits_h = xyes; then echo '#include ' >> $outfile fi if test x$glib_float_h = xyes; then echo '#include ' >> $outfile fi if test x$glib_values_h = xyes; then echo '#include ' >> $outfile fi (glib_values_h is set to yes only if limits.h or float.h is missing). Instead, it should define GLIB_HAVE_LIMITS_H, GLIB_HAVE_FLOAT_H and GLIB_HAVE_VALUES_H to 1, if the headers are available. Another file, say gnutls-features.h, would #include and then: #if GLIB_HAVE_LIMITS_H # include #elif GLIB_HAVE_VALUES_H # include #endif #if GLIB_HAVE_FLOAT_H # include #elif GLIB_HAVE_VALUES_H # include #endif Simon said that public header should work with any of the compilers on the host. While we cannot fully achieve this, this setup can help. If the description in gnutlconfig.h happens to be inacurate, the user can supply it's own copy, editing some of the bits. (It might even work! ;-) This rationale is similar to why we have config.h.in; in rare cases, users can use it as a form to fill... Another reason is that the constant gnutls-features.h header shows all the possible alternatives, and gnutlsconfig.h selects which should be executed. With glib, I cannot see the other alternatives, unless I look into configure.in. (Which is not installed, of course.) A few days ago I consulted glibconfig.h for the definition of G_GINT64_CONSTANT. I saw only one definition, so I assumed it's the only one. Perhaps I have compromised the portability of the package I was working on, because of that false assumption. Hope this essay will help you to make the right decision. ;-) Happy hacking, Stepan Kasal ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] synced mktime.c and strtol.c from intprops.h
Hello, On Thu, Aug 25, 2005 at 09:21:00AM -0700, Paul Eggert wrote: > > What would be wrong with the following patch? > > Synchronization with glibc. mktime.c is shared with the GNU C > Library, and glibc doesn't have intprops.h. thanks for explanation. I'm dropping the patch. > I suppose that we could migrate intprops.h into glibc, but that would Yes, that might take some effort... Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: error: possibly undefined macro: AC_CHECK_HEADERS_ONCE
Hello, On Thu, Aug 25, 2005 at 05:06:55PM +0200, Bruno Haible wrote: > AC_INIT(regexp, 1.0, clisp-list) > +AC_GNU_SOURCE > AC_CONFIG_SRCDIR(regexp.lisp) > That might be a little too early, [...] > I would put it after the determination of CC and CPP, but > before all AC_CHECK_HEADER and AC_CHECK_FUNC tests: >... > AC_PROG_CC > AC_PROG_CPP > AC_AIX > +AC_GNU_SOURCE > AC_HEADER_STDC yes, this is probably a good idea. The gnulib manual also says that gl_EARLY should be called right after AC_PROG_CC. But as far as the artificial configure.ac is concerned, I think calling AC_GNU_SOURCE right after AC_INIT doesn't make it worse, so it can be left the way I did it. > [...] because AC_GNU_SOURCE emits a definition into the config header, > but before AC_CONFIG_HEADERS it doesn't know the file name... No, AC_CONFIG_HEADERS has nothing to do with this. During the run of ./configure, the AC_DEFINES are collected. At the end of the day, AC_OUTPUT engraves them all into all config headers. >From the perspective of Autoconf and ./configure, config headers can be declared anywhere (between AC_INIT and AC_OUTPUT, of course). >From the perspective of autoheader, the name of the first of the declared config headers is important. But autoheader doesn't care about AC_DEFINEs, and it has nothing to do with ./configure execution. All these facts should be deducable from the Autoconf manual. I have recently fixed some of this in CVS; if the CVS version of manual doesn't describe the situation clearly, suggestions are welcome. Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: check-module
Hello, On Mon, Jul 11, 2005 at 02:38:23PM +0200, Stepan Kasal wrote: > 2005-07-11 Bruno Haible <[EMAIL PROTECTED]> > and Stepan Kasal <[EMAIL PROTECTED]> > > * check-module: If more parameters are given, check each of them > separately; add more exceptions, as noted by Jim Meyering. > (check_module): New procedure. > (%exempt_header): Now contains all exceptions. Jim has just committed this patch. Thanks. Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: socklen_t
Hello, On Thu, Sep 01, 2005 at 04:43:30AM -0500, Albert Chin wrote: > for arg2 in "struct sockaddr" void; do > for t in int size_t unsigned long "unsigned long"; do >AC_TRY_COMPILE([ > #include > #include > > int getpeername (int, $arg2 *, $t *); >],[ > $t len; > getpeername(0,0,&len); >],[ > socklen_t_equiv="$t" > break >]) > done > done I see two problems with this code: 1) Wouldn't "break 2" be more appropriate? 2) The use of `break' or `continue' inside `AC_*_IFELSE' (or the obsolete AC_TRY_*) is not safe; it skips the cleanup of that macro. Something like this is better: ... ],[ socklen_t_equiv="$t" ]) done test -z "$socklen_t_equiv" && break done if -z "$socklen_t_equiv"; then AC_MSG_ERROR([Cannot find a type to use in place of socklen_t]) fi Have a nice day, Stepan Kasal ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Preprocessor directives formatting
Hello, On Tue, Sep 13, 2005 at 10:23:32AM -0400, Derek Price wrote: > [...] double-include protection should be ignored for the purposes of > indenting compiler directives in headers, ... > I would note that GNU indent doesn't currently support Paul's style. It > supports intentation of cpp directives, but only to leave them > unmodified or to indent them by a set # of spaces per nested block, > without an option to make an exception for the first #if block encountered. that is a serious flaw in indent-2.2.9. A new option should be added for this: if the whole file is one big #ifndef..#endif, this outermost #ifdef would be ignored. It should be on by default. Moreover, two of the three options you mentioned are not properly documented: --preprocessor-indentationN-ppiN --remove-preprocessor-space-nlps They are missing from `Option Summary', both from the list of descriptions and from the `Cross Key' table below. I'm not sure whether indent is actively developped, but at least this bug report is filed in bug-indent archives now. Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: regex-0.12's regex.h seems to have a little bug
Hi, I don't say I'm excited about the AC_LIBSOURCE macro, ... On Wed, Sep 21, 2005 at 11:02:24AM +0200, Simon Josefsson wrote: > I'm not sure what the supposed advantage with > AC_LIBSOURCES was compared to the old scheme. ... but I think I do remember what was the advantage: Imagine that a new file baz.c is added to a module. Then it is possible that you upgrade the existing files, including the m4 file which checks whether baz.c is needed, but that you forget to copy the new file, or you forget to add it to the list of distributed files. With the old scheme, the bug would be detected only on platforms where baz.c is needed. Typically, the developper uses a variant of GNU system, so most of the replacements are not needed; so the bug is not detected on his platform. With the AC_LIBSOURCES, Automake uses traces to obtain the list of distributed files, so we are sure that baz.c will be distributed. (And if it wasn't copied into the project, Automake will complain on every platform, no matter whether the file would be actually built there.) Yes, you might object that the mistake described above will not happen when people use gnulib-tool. But: - with the old scheme, the module maintainer had to add the file to the module description, _twice_: to the file list and to the lib_SOURCES variable in Makefile.am section. - with the new scheme you only add something like if test "$baz_works" != yes; then AC_LIBOBJ([baz]) fi and it expands to AC_LIBSOURCE([baz.c]) which is traced by Automake. Please note that almost always you need to add a check for the feature anyway, so the code required by the new scheme presents almost no overhead, and, more importantly, the risk that you forget to add it is minimal. So that's it. Stepan Kasal ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: regex-0.12's regex.h seems to have a little bug
Hello, On Wed, Sep 21, 2005 at 05:13:24PM +0200, Simon Josefsson wrote: > I think AC_LIBSOURCE probably is > the right solution, but it would have been nice to introduce it after > the autoconf/automake/libtool/m4 releases had happened. [...] > Requiring modern tools for gnulib users is probably > ok, but requiring unreleased cvs releases probably is not. ... > Problem is, the new scheme causes real problems if you used AC_LIBOBJ > or AC_REPLACE_FUNCS before, and put the LTLIBOBJ in another directory > than the gnulib files. when AC_LIBSOURCE was introduced, we all thought that this problem is not big enough in practice. Later on, when it was realized that a fix is needed, it was decided to wait for Autoconf 2.60, instead of converting gnulib back to the old scheme and later again to the new one. > Module maintainers always has to do the right thing. This potential > mistake is possible to detect through a script, so if this was a > genuine problem in the old scheme, we could write that script. > > > - with the new scheme you only add something like > > if test "$baz_works" != yes; then > > AC_LIBOBJ([baz]) > > fi > > and it expands to AC_LIBSOURCE([baz.c]) which is traced by Automake. > > This doesn't seem like a huge improvement. Having information on one place instead of having it stored redundantly is always good. Script to check that the redundant description are consistent is a kludge. Stepan Kasal ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: regex-0.12's regex.h seems to have a little bug
Hello, On Thu, Sep 22, 2005 at 12:36:46PM +0200, Simon Josefsson wrote: > Stepan Kasal <[EMAIL PROTECTED]> writes: > > Later on, when it was realized that a fix is needed, it was decided to wait > > for Autoconf 2.60, instead of converting gnulib back to the old scheme and > > later again to the new one. > > Right, sure. Btw, can I test this now? Is autoconf CVS HEAD > sufficient? Do I need other tools from CVS? oops, we got too far. I'm afraid I no longer know what I'm speaking about. :-( What was the problem? That you cannot use AC_LIBOBJ/AC_LIBSOURCE with more than one "lib" subdirectory, right? What was the proposed solution? I'm not sure, I'm afraid I have missed it. But I _think_ that a prerequisite of the solution was that AC_LIBSOURCES and AC_LIBOBJ would take a second parameter which would specify the "group" that the file belongs to. This prerequisite is not in CVS Autoconf. I'm afraid we need a design document for the solution. Then we can implement it. Have I missed it, or it is yet to be written? The following doesn't seem to be much relevant now, but: > I recall some release dependency tree. CVS Automake requires CVS Autoconf. The other dependecies are not relevant here: CVS m4 requires CVS libtool (a.k.a. libtool 2.0). And perhaps CVS libtool depends on something, too... Happy hacking ;-) Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: regex-0.12's regex.h seems to have a little bug
Hello, > > I'm afraid we need a design document for the solution. Then we can > > implement it. Have I missed it, or it is yet to be written? > > No, I don't think you've missed it; that work still needs to be done. but I'm not able to do it. Simon, perhaps you could volunteer. Could you please prepare an example project, quickly recap the problem, explain your needs, and then implement the user side of the solution. I mean your solution would use no-yet-existent features of Autoconf, but you'd explain what you are expecting from Autoconf (and Automake). This would be a form of detailed design document. Do you have time and interest to do this? Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: regex-0.12's regex.h seems to have a little bug
Hello again, On Fri, Sep 23, 2005 at 10:33:21AM +0200, Stepan Kasal wrote: > > > I'm afraid we need a design document for the solution. > Simon, perhaps you could volunteer. ... or you can just wait. I think I have something in mind now, and hopefully I'll write it down sometimes next week. Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Redundant AC_LIBSOURCES calls
Hello, I propose the patch attached below; an explanation follows: I think that when AC_LIBOBJ and friends was designed, the idea was to use some testing if foo_is_broken; then AC_LIBOBJ([foo]) fi The AC_LISOURCE/AC_LIBSOURCES macros were also made visible, so that the user can name additional sources, when necessary. Actually, gnulib needs foo.h in most cases, because the module fixes also a broken declaration, not only broken implementation. But in the basic case, when only the implementation is fixed and no header is needed, I see no advantage in adding a redundant call to AC_LIBSOURCES. Have a nice day, Stepan Kasal 2005-09-23 Stepan Kasal <[EMAIL PROTECTED]> * m4/gettime.m4, m4/getugroups.m4, m4/idcache.m4, m4/inttostr.m4, m4/nanosleep.m4, m4/settime.m4: Remove redundant AC_LIBSOURCES. Index: m4/gettime.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/gettime.m4,v retrieving revision 1.4 diff -u -r1.4 gettime.m4 --- m4/gettime.m4 26 Feb 2005 08:18:27 - 1.4 +++ m4/gettime.m4 23 Sep 2005 09:57:45 - @@ -6,7 +6,6 @@ AC_DEFUN([gl_GETTIME], [ - AC_LIBSOURCES([gettime.c]) AC_LIBOBJ([gettime]) dnl Prerequisites of lib/gettime.c. Index: m4/getugroups.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/getugroups.m4,v retrieving revision 1.4 diff -u -r1.4 getugroups.m4 --- m4/getugroups.m421 Mar 2005 22:06:27 - 1.4 +++ m4/getugroups.m423 Sep 2005 09:57:45 - @@ -6,7 +6,6 @@ AC_DEFUN([gl_GETUGROUPS], [ - AC_LIBSOURCES([getugroups.c]) AC_LIBOBJ([getugroups]) dnl Prerequisites of lib/getugroups.c. Index: m4/idcache.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/idcache.m4,v retrieving revision 1.4 diff -u -r1.4 idcache.m4 --- m4/idcache.m4 21 Mar 2005 22:06:27 - 1.4 +++ m4/idcache.m4 23 Sep 2005 09:57:45 - @@ -6,7 +6,6 @@ AC_DEFUN([gl_IDCACHE], [ - AC_LIBSOURCES([idcache.c]) AC_LIBOBJ([idcache]) dnl Prerequisites of lib/idcache.c. Index: m4/inttostr.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/inttostr.m4,v retrieving revision 1.4 diff -u -r1.4 inttostr.m4 --- m4/inttostr.m4 21 Mar 2005 22:06:27 - 1.4 +++ m4/inttostr.m4 23 Sep 2005 09:57:45 - @@ -8,11 +8,6 @@ [ AC_LIBSOURCES([inttostr.c, inttostr.h, intprops.h]) - dnl We don't technically need to list the following .c files, since their - dnl functions are named in the AC_LIBOBJ calls, but this is an unusual - dnl module and it seems a little clearer to do so. - AC_LIBSOURCES([imaxtostr.c, offtostr.c, umaxtostr.c]) - AC_LIBOBJ([imaxtostr]) AC_LIBOBJ([offtostr]) AC_LIBOBJ([umaxtostr]) Index: m4/nanosleep.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/nanosleep.m4,v retrieving revision 1.20 diff -u -r1.20 nanosleep.m4 --- m4/nanosleep.m4 2 May 2005 07:00:50 - 1.20 +++ m4/nanosleep.m4 23 Sep 2005 09:57:45 - @@ -12,8 +12,6 @@ AC_DEFUN([gl_FUNC_NANOSLEEP], [ - AC_LIBSOURCES([nanosleep.c]) - nanosleep_save_libs=$LIBS # Solaris 2.5.1 needs -lposix4 to get the nanosleep function. Index: m4/settime.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/settime.m4,v retrieving revision 1.4 diff -u -r1.4 settime.m4 --- m4/settime.m4 21 Mar 2005 22:06:27 - 1.4 +++ m4/settime.m4 23 Sep 2005 09:57:45 - @@ -6,7 +6,6 @@ AC_DEFUN([gl_SETTIME], [ - AC_LIBSOURCES([settime.c]) AC_LIBOBJ([settime]) dnl Prerequisites of lib/settime.c. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] Redundant AC_LIBSOURCES calls
Hello, On Fri, Sep 23, 2005 at 02:37:06PM +0200, Bruno Haible wrote: > Stepan Kasal wrote: > > But in the basic case, when only the implementation is fixed and no > > header is needed, I see no advantage in adding a redundant call to > > AC_LIBSOURCES. > > The advantage is simplicity and consistency. I thought you would object... ;-) It's only a matter of style and preferrence, no big deal. > Your approach is even worse: It forces the maintainer to look or grep > for AC_LIBOBJ invocations in the autoconf macros. And not only in the > package's *.m4 files, but also in autoconf's and automake's own *.m4 files! > It opens the door to problems that will appear with one version of autoconf > and not with another... > > Too much magic -> implies -> too much complexity when debugging. The magic is already there: AC_LIBOBJ calls AC_LIBSOURCE since 2.50 when it was introduced. I don't see any chance to remove it now. This magic can complicate debugging, yes. Even though gnulib uses the redundant style, the magic is still hidden behind, ready to bite you! OK, forget about it. Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
problems in stdbool.m4
Hello, I noticed two problems with stdbool.m4: Even with Autoconf-2.59, this file is included in aclocal.m4, and thus the gnulib definition overrides the Autoconf one. Perhaps the following would fix it: m4_ifndef([AC_HEADER_STDBOOL], AC_DEFUN([AC_HEADER_STDBOOL], [... ]) ]) Second, AM_STDBOOL_H is misnamed. Wouldn't gl_STDBOOL_H be better? Wdyt? Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: restrict.m4: do not punish autoconf 2.59 users
Hello,
> AC_DEFUN([gl_C_RESTRICT],
> -[AC_CACHE_CHECK([for C/C++ restrict keyword], gl_cv_c_restrict,
> +[m4_ifdef([AC_C_RESTRICT], [AC_C_RESTRICT],
> + [AC_CACHE_CHECK([for C/C++ restrict keyword], gl_cv_c_restrict,
perhaps
m4_ifndef([AC_C_RESTRICT],
AC_DEFUN([gl_C_RESTRICT],
[...]
])
])
could be better.
But: how many people are using current gnulib with Autoconf 2.57 or earlier?
I know it is only two releases behind the latest, but OTOH, it is
3 years old.
Current gnulib is mostly used for bootstraps of CVS checkouts, so I guess
requiring Autoconf 2.59 may not be a bad idea.
Have a nice day,
Stepan Kasal
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: restrict.m4: do not punish autoconf 2.59 users
Hello, On Wed, Oct 12, 2005 at 08:33:28PM +0200, Bruno Haible wrote: > Stepan Kasal wrote: > > m4_ifndef([AC_C_RESTRICT], > > AC_DEFUN([gl_C_RESTRICT], ... > > could be better. > > And what would we put into modules/restrict then? sorry, this was a mistake, I meant: m4_ifndef([AC_C_RESTRICT], AC_DEFUN([AC_C_RESTRICT], so we would put AC_C_RESTRICT into the configure.ac section. Would you like this? > > But: how many people are using current gnulib with Autoconf 2.57 or > > earlier? Actually, I thought the answer might be 0, without any substantial chance that it'll increase. > There is no need to spend time discussing this. It is not useful to > gratuitously reduce the number of available choices, and you have not > said why supporting autoconf-2.57 would be a problem. No big problem, of course. Let's forget about this second proposal. Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] problems in stdbool.m4
Hello, On Wed, Oct 12, 2005 at 08:23:29PM +0200, Bruno Haible wrote: > Stepan Kasal wrote: > > I noticed two problems with stdbool.m4: > > > > Even with Autoconf-2.59, this file is included in aclocal.m4, > > and thus the gnulib definition overrides the Autoconf one. > > This is what we want. Look at the comment: > -- > # This macro is only needed in autoconf <= 2.59. Newer versions of autoconf > # have this macro built-in. > > AC_DEFUN([AC_HEADER_STDBOOL], but 2.59 has it's own version of AC_HEADER_STDBOOL, though slightly different from Autoconf-CVS. And the gnulib copy is different from what Autoconf-2.59 has. > > m4_ifndef([AC_HEADER_STDBOOL], > > AC_DEFUN([AC_HEADER_STDBOOL], > Nope, this would be a regression. Oh, I understand now. But I don't think gnulib should redefine documented Autoconf macros. What about renaming it to gl_HEADER_STDBOOL ? Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: arcfour
Hello, Ralf proposed: > > > #define ARCFOUR_BLOCKBITS 8 we have a random number generator, which gives us a sequence of 8-bit integers. So, in a sense, we are working with 8-bit blocks. But I see no reason why the other constants should contain the substring "BLOCK". On Fri, Oct 14, 2005 at 04:01:23PM +0200, Ralf Wildenhues wrote: > Come to think of it, I'd probably call the first one LOGSZ > (or LOGSIZE, FWIW), and the second SIZE. The first one might be ARCFOUR_BLOCKBITS, but ARCFOUR_LOGSZ might be better, to avoid misunderstanding. The second one should be ARCFOUR_SIZE. Perhaps: #define ARCFOUR_LOGSZ 8 #define ARCFOUR_SIZE (1 << ARCFOUR_LOGSZ) /* Some compilers may not be able to optimize n % ARCFOUR_SIZE properly. */ #define ARCFOUR_MODULO(n) ((n) & (ARCFOUR_SIZE - 1)) You asked Simon to use constants, to make the code more general. But there is actually no need that the SIZE of the permutation (sbox) be a power of 2. It can be any positive number, in theory. Yes, the size of the sbox determines the range of the numbers generated, so if ARCFOUR_SIZE is not a power of 2, then the pseuso-random genrator is not directly applicable for enciphering a binary data, but that's just a detail. So, in a sense, it would be better to use i % ARCFOUR_SIZE, instead of i & ARCFOUR_MASK. But, OTOH, we are not willing to compromise the performance, not even with less capable compilers. I think the macro ARCFOUR_MODULO proposed above might be a good solution. Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: arcfour
Hello, On Fri, Oct 14, 2005 at 04:14:09PM +0200, Simon Josefsson wrote: > Internally, in arcfour.c, [...] > #define ARCFOUR_MOD_MASK (ARCFOUR_SBOX_SIZE - 1) yes, this is a good idea, and it also applies to the proposal I have just posted: These two would be in .h: #define ARCFOUR_LOGSZ 8 /* or ARCFOUR_BLOCK_BITS */ #define ARCFOUR_SIZE (1 << ARCFOUR_LOGSZ) while this would be in .c /* Some compilers may not be able to optimize n % ARCFOUR_SIZE properly. */ #define ARCFOUR_MODULO(n) ((n) & (ARCFOUR_SIZE - 1)) Regarding the ARCFOUR_SIZE alias ARCFOUR_SBOX_SIZE: Perhaps we could call it ARCFOUR_BASE: all arithmetics is done modulo this number. The fact that this is also the size of the domain of the permutation (sbox) is just a consequence. Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: gnulib-tool tweaks
Hi Bruno, and what about the following? Stepan 2005-10-17 Stepan Kasal <[EMAIL PROTECTED]> * gnulib-tool (func_create_testdir): Omit the clumsy check whether BUILT_SOURCES in nonempty. Index: gnulib-tool === RCS file: /cvsroot/gnulib/gnulib/gnulib-tool,v retrieving revision 1.86 diff -u -r1.86 gnulib-tool --- gnulib-tool 17 Oct 2005 10:27:37 - 1.86 +++ gnulib-tool 17 Oct 2005 15:26:39 - @@ -1516,11 +1516,8 @@ (cd "$testdir" ./configure cd lib - built_sources=`grep '^BUILT_SOURCES *=' Makefile.in | sed -e 's/^BUILT_SOURCES *=//'` - if test -n "$built_sources"; then - echo 'built_sources: $(BUILT_SOURCES)' >> Makefile - make built_sources - fi + echo 'built_sources: $(BUILT_SOURCES)' >> Makefile + make built_sources cd .. make distclean ) ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: problems in stdbool.m4
Hello, On Fri, Oct 14, 2005 at 01:57:00PM +0200, Bruno Haible wrote: > We do override include files by using our own if the system's one is > defective. ... > We do override an autoconf macro if it is buggy. yes, that makes sense. Thanks for explaining. Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: gc-md4 and gc-md4-tests
Hello,
> + AC_DEFINE(GC_USE_MD4, 1, [Define to if you want to support MD4 through
> GC.])
I'd suggest
s/Define to if/Define if/
this applies to:
m4/gc-hmac-md5.m4
m4/gc-hmac-sha1.m4
m4/gc-md4.m4
m4/gc-md5.m4
m4/gc-sha1.m4
Have a nice day,
Stepan Kasal
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: md5 cleanup
Hello, On Sun, Oct 23, 2005 at 10:34:18PM -0700, Paul Eggert wrote: > uint32_t *p = (uint32_t *) ((char *) ctx->buffer + bytes + pad); > p[0] = SWAP (ctx->total[0] << 3); > p[1] = SWAP ((ctx->total[1] << 3) | (ctx->total[0] >> 29)); wouldn't the following be more readable? uint32_t bytes = ctx->buflen; size_t size = (bytes < 56) ? 64 / 4 : 64 * 2 / 4; /* Now count remaining bytes. */ ctx->total[0] += bytes; if (ctx->total[0] < bytes) ++ctx->total[1]; /* Put the 64-bit file length in *bits* at the end of the buffer. */ ctx->buffer[size - 2] = SWAP (ctx->total[0] << 3); ctx->buffer[size - 1] = SWAP ((ctx->total[1] << 3) | (ctx->total[0] >> 29)); memcpy (&((char*)ctx->buffer)[bytes], fillbuf, (size - 2) * 4 - bytes); /* Process last bytes. */ md5_process_block (ctx->buffer, size * 4, ctx); Do I understand correctly that this is only executed for the last block, so that it's not necessary to be so careful about each tick? Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: namespace conflict for des
Hello, On Sun, Oct 23, 2005 at 10:25:48PM -0700, Paul Eggert wrote: > Simon Josefsson <[EMAIL PROTECTED]> writes: > > In file included from smbutil.c:34: > > lib/des.h:62: conflicting types for `des_setkey' ... > If they are supposed to have the same semantics but the FreeBSD > versions are buggy, you could rename the functions in unistd.h > instead, by using #define before #include . It's a bit of a > hack, as it requires that client code to include your .h file before > it includes unistd.h. I suppose another possibility is to use linker > magic but this is a bit less portable in practice. wouldn't it be better if lib/des.h contained #include #define des_setkey rpl_des_setkey What am I missing? Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Don't bother checking for unistd.h
Hi, would the following patch be welcome? I haven't noticed any of the files in config/srclist.txt. Stepan 2005-10-24 Stepan Kasal <[EMAIL PROTECTED]> * c-stack.m4, copy-file.m4, execute.m4, fatal-signal.m4, findprog.m4, getlogin_r.m4, pagealign_alloc.m4, pipe.m4, wait-process.m4: Don't bother checking for unistd.h. 2005-10-24 Stepan Kasal <[EMAIL PROTECTED]> * c-stack.c, copy-file.c, execute.c, fatal-signal.c, findprog.c, getlogin_r.c, getlogin_r.h, pagealign_alloc.c, pipe.c, pipe.h, progreloc.c, wait-process.h: Don't bother checking for unistd.h. Index: lib/c-stack.c === RCS file: /cvsroot/gnulib/gnulib/lib/c-stack.c,v retrieving revision 1.7 diff -u -r1.7 c-stack.c --- lib/c-stack.c 19 Sep 2005 17:28:14 - 1.7 +++ lib/c-stack.c 24 Oct 2005 14:03:48 - @@ -62,6 +62,7 @@ #include #include +#include #if HAVE_SYS_RESOURCE_H /* Include sys/time.h here, because... @@ -77,9 +78,6 @@ # include #endif -#if HAVE_UNISTD_H -# include -#endif #ifndef STDERR_FILENO # define STDERR_FILENO 2 #endif Index: lib/copy-file.c === RCS file: /cvsroot/gnulib/gnulib/lib/copy-file.c,v retrieving revision 1.6 diff -u -r1.6 copy-file.c --- lib/copy-file.c 19 Sep 2005 17:28:14 - 1.6 +++ lib/copy-file.c 24 Oct 2005 14:03:48 - @@ -28,10 +28,7 @@ #include #include #include - -#ifdef HAVE_UNISTD_H -# include -#endif +#include #if HAVE_UTIME || HAVE_UTIMES # if HAVE_UTIME_H Index: lib/execute.c === RCS file: /cvsroot/gnulib/gnulib/lib/execute.c,v retrieving revision 1.3 diff -u -r1.3 execute.c --- lib/execute.c 14 May 2005 06:03:58 - 1.3 +++ lib/execute.c 24 Oct 2005 14:03:48 - @@ -29,10 +29,7 @@ #include #include #include - -#ifdef HAVE_UNISTD_H -# include -#endif +#include #include "error.h" #include "exit.h" Index: lib/fatal-signal.c === RCS file: /cvsroot/gnulib/gnulib/lib/fatal-signal.c,v retrieving revision 1.6 diff -u -r1.6 fatal-signal.c --- lib/fatal-signal.c 19 Sep 2005 17:28:14 - 1.6 +++ lib/fatal-signal.c 24 Oct 2005 14:03:48 - @@ -28,9 +28,7 @@ #include #include #include -#if HAVE_UNISTD_H -# include -#endif +#include #include "xalloc.h" Index: lib/findprog.c === RCS file: /cvsroot/gnulib/gnulib/lib/findprog.c,v retrieving revision 1.4 diff -u -r1.4 findprog.c --- lib/findprog.c 19 Sep 2005 17:28:14 - 1.4 +++ lib/findprog.c 24 Oct 2005 14:03:48 - @@ -27,10 +27,7 @@ #include #include #include - -#ifdef HAVE_UNISTD_H -# include -#endif +#include #include "xalloc.h" #include "pathname.h" Index: lib/getlogin_r.c === RCS file: /cvsroot/gnulib/gnulib/lib/getlogin_r.c,v retrieving revision 1.4 diff -u -r1.4 getlogin_r.c --- lib/getlogin_r.c19 Sep 2005 17:28:14 - 1.4 +++ lib/getlogin_r.c24 Oct 2005 14:03:48 - @@ -26,10 +26,7 @@ #include #include - -#if HAVE_UNISTD_H -# include -#endif +#include #if !HAVE_DECL_GETLOGIN char *getlogin (void); Index: lib/getlogin_r.h === RCS file: /cvsroot/gnulib/gnulib/lib/getlogin_r.h,v retrieving revision 1.5 diff -u -r1.5 getlogin_r.h --- lib/getlogin_r.h11 Jul 2005 11:21:55 - 1.5 +++ lib/getlogin_r.h24 Oct 2005 14:03:48 - @@ -19,10 +19,7 @@ /* Written by Paul Eggert and Derek Price. */ #include - -#if HAVE_UNISTD_H -# include -#endif +#include /* Copies the user's login name to NAME. The array pointed to by NAME has room for SIZE bytes. Index: lib/pagealign_alloc.c === RCS file: /cvsroot/gnulib/gnulib/lib/pagealign_alloc.c,v retrieving revision 1.8 diff -u -r1.8 pagealign_alloc.c --- lib/pagealign_alloc.c 2 Jul 2005 09:45:08 - 1.8 +++ lib/pagealign_alloc.c 24 Oct 2005 14:03:48 - @@ -27,12 +27,8 @@ #include #include - #include - -#if HAVE_UNISTD_H -# include -#endif +#include #if HAVE_MMAP # include Index: lib/pipe.c === RCS file: /cvsroot/gnulib/gnulib/lib/pipe.c,v retrieving revision 1.4 diff -u -r1.4 pipe.c --- lib/pipe.c 19 Sep 2005 17:28:14 - 1.4 +++ lib/pipe.c 24 Oct 2005 14:03:48 - @@ -28,10 +28,7 @@ #include #include #include - -#ifdef HAVE_UNISTD_H -# include -#endif +#include #include "error.h" #include "exit.h" Index: lib/pipe.h ==
Re: check for readline
Hello, I have noticed a typo in lib/readline.c: > "This module is intended to be used when the application only need > the readline interface. [...] the first line should end "... needs". Have a nice day, Stepan Kasal ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
stat-time systemology update?
Hello, the top of m4/stat-time.m4 says: # st_atim.tv_nsec - Linux, Solaris, Cygwin # st_atimespec.tv_nsec - FreeBSD, NetBSD, if ! defined _POSIX_SOURCE # st_atimensec - FreeBSD, NetBSD, if defined _POSIX_SOURCE # st_atim.st__tim.tv_nsec - UnixWare (at least 2.1.2 through 7.1) But my GNU libc.info mentiones st_atimensec, but not st_atim. So it seems that platforms using GNU libc (GNU/Linux, Cygwin?) are converging towards POSIX. Yes, this is a minor problem, but if this mail makes one of the portability wizards to do a rough adjustment of the comment, it might helt to the others. Thanks, Stepan
Re: stat-time systemology update?
Hello again, I'm sorry that I was too quick writing my previous mail. On Wed, Oct 17, 2007 at 11:34:54AM +0200, Stepan Kasal wrote: > But my GNU libc.info mentiones st_atimensec, but not st_atim. > > So it seems that platforms using GNU libc (GNU/Linux, Cygwin?) are > converging towards POSIX. I was wrong here. st_atim seems to be the prefferred one, in current GNU libc and POSIX draft. So the only problem is that libc.info is obsolete, I'm going to report that. Sorry, Stepan
