Re: nanosleep module and mingw32
Simon Josefsson <[EMAIL PROTECTED]> wrote: ... > Wouldn't this be a good situation to have nanosleep depend on the > unistd module, and make the replacement unistd.h include winsock2.h on > mingw32 platforms? After all, nanosleep.c include unistd.h, and > unistd.h define select on some platforms. Yes, I'd prefer that. Did you (Simon) just volunteer? :)
Re: [bug-gnulib] Re: nanosleep module and mingw32
Simon Josefsson wrote: > Wouldn't this be a good situation to have nanosleep depend on the > unistd module, and make the replacement unistd.h include winsock2.h on > mingw32 platforms? After all, nanosleep.c include unistd.h, and > unistd.h define select on some platforms. But is not supposed to declare select() in POSIX: see http://www.opengroup.org/onlinepubs/009695399/functions/select.html POSIX says should declare it. is unrelated. Since gnulib's policy is to let the programs write code in POSIX syntax, I vote for a module that creates a file in the build directory. On most platforms it would need to include too; on Woe32 it would use . full-header-path.m4 comes in handy here. Bruno
comment in getugroups.c
This fixes an outdated comment in getugroups.c. getgrent et al. are part of POSIX/XSI since the Base Specifications Version 5. *** gnulib-20060430/lib/getugroups.c2005-09-23 06:15:13.0 +0200 --- gnulib-20060430-modified/lib/getugroups.c 2006-05-19 00:46:28.0 +0200 *** *** 34,41 # define EOVERFLOW EINVAL #endif ! /* setgrent, getgrent, and endgrent are not specified by POSIX.1, !so header files might not declare them. If you don't have them at all, we can't implement this function. You lose! */ struct group *getgrent (); --- 34,40 # define EOVERFLOW EINVAL #endif ! /* Some old header files might not declare setgrent, getgrent, and endgrent. If you don't have them at all, we can't implement this function. You lose! */ struct group *getgrent ();
Re: comment in getugroups.c
Bruno Haible <[EMAIL PROTECTED]> wrote: > This fixes an outdated comment in getugroups.c. getgrent et al. are part > of POSIX/XSI since the Base Specifications Version 5. Applied. Thanks.
Re: [bug-gnulib] getgrouplist
Jim Meyering wrote: > It'd be great if someone would write a gnulib-style getgrouplist > replacement function that provides a poor-man's implementation (using > something like coreutils' existing code) for systems that lack a useful > function by that name. Here is an implementation of the getgrouplist module you ask for. It is based on the getugroups.c file. About the glibc-2.3.2 bug workaround: - I don't know how to write an autoconf test for the bug (take e.g. a system where all users are only in their primary group). - The bug is unlikely to be present in other systems, therefore activating the workaround only on glibc-2.3.x seems acceptable. - Even on glibc-2.3.2 systems which have the bug, the getgrouplist function can be used if a protection against the destination overflow is installed. And if it's really faster than a getgrent() loop, it _should_ be used. The overhead added by the workaround is a small number of library calls (2 x sigaction, 1 x setjmp, 1 x memcpy). Notes: - The array element type is gid_t. I don't see why the GETGROUPS_T workaround should be applied to a function that is up to now only implemented by glibc. - The group argument can be any gid_t; if you pass (gid_t)(-1), you will have (gid_t)(-1) in the resulting array. This is how glibc's implementation works; therefore this implementation works the same. Whereas the getugroups() function treated (gid_t)(-1) specially. - The getgrent() loop in getugroups.c is O(n^2). I reduced this to O(n log n). You could also make it O(n) by use of a hash table. Proofreading welcome, as always! This is new, untested code. 2006-05-18 Bruno Haible <[EMAIL PROTECTED]> * m4/getgrouplist.m4: New file. * lib/getgrouplist.h: New file. * lib/getgrouplist.c: New file, based on lib/getugroups.c. * modules/getgrouplist: New file. = modules/getgrouplist = Description: getgrouplist() function: return all the group IDs of a given user. Files: lib/getgrouplist.h lib/getgrouplist.c m4/getgrouplist.m4 Depends-on: configure.ac: gl_FUNC_GETGROUPLIST Makefile.am: EXTRA_DIST += getgrouplist.h Include: #include "getgrouplist.h" License: GPL Maintainer: Jim Meyering, Bruno Haible = lib/getgrouplist.h = /* Lookup of groups of a user. Copyright (C) 2006 Free Software Foundation, Inc. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ #ifndef _GETGROUPLIST_H #define _GETGROUPLIST_H #include #if HAVE_GETGROUPLIST && !(defined __GNU_LIBRARY__ && (__GLIBC__ == 2 && __GLIBC_MINOR__ == 3)) /* Use the system's getgrouplist() function. */ # include #else /* Return the groups to which the user with name USER belongs, including the given GROUP. GROUPS is a pointer to *NGROUPS elements. Up to *NGROUPS elements are stored at GROUPS. Upon return *NGROUPS is then set to the total number of elements that would have been stored if enough space had been given. Return the number of elements, if they all fit into the given space, or -1 if only some of the elements could be stored. */ extern int getgrouplist (const char *user, gid_t group, gid_t *groups, int *ngroups); #endif #endif /* _GETGROUPLIST_H */ = lib/getgrouplist.c = /* Lookup of groups of a user. Copyright (C) 1990-1991, 1998-2000, 2003-2006 Free Software Foundation, Inc. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ /* Written by David MacKenzie and Bruno Haible. */ #ifdef HAVE_CONFIG_H # include #end
Re: Cygwin && WIN32
Paul Eggert wrote: > > In other places I used to define WIN32 as an abbreviation of > > defined _WIN32 || defined __WIN32__ > > Now I'm renaming that to WIN32_NATIVE. > > Would WOE32_NATIVE be a better name? I don't know. I use the term "Woe32" when I talk about the platform which is not a win. But in code? Some people might be really disgusted when they have to read code with pejorative terms: #ifdef WOE32_NATIVE #ifdef UNIX_SLOWLARIS #ifdef UNIX_DELIRIX Many people believe code should be neutral. Bruno
standards.texi language cleanup (was: Cygwin && WIN32)
* Bruno Haible wrote on Fri, May 19, 2006 at 03:07:01PM CEST: > Paul Eggert wrote: > > > > Would WOE32_NATIVE be a better name? > > Many people believe code should be neutral. FWIW, I agree. After all, POSIX_ME_HARDER was dropped, too. I removed occurrences of M$VC and *BSD from the Libtool sources, after being notified about them: I want to be able to work with people, not against them. And the people that take issue with these are _not_ equal to the system or compiler you may have issues with, if any. Speaking of which, can we please change this, now that I noticed it? Some people have an issue with this notation, and I don't want to see this in the Autoconf tarball. Cheers, Ralf 2006-05-19 Ralf Wildenhues <[EMAIL PROTECTED]> * doc/standards.texi (System Portability): Spell out `free BSD variants', instead of using the term `*BSD'. Index: doc/standards.texi === RCS file: /cvsroot/gnulib/gnulib/doc/standards.texi,v retrieving revision 1.15 diff -u -r1.15 standards.texi --- doc/standards.texi 8 May 2006 13:22:22 - 1.15 +++ doc/standards.texi 19 May 2006 13:30:46 - @@ -2654,11 +2654,11 @@ are the form of GNU that is popular. Beyond that, it is good to support the other free operating systems -(*BSD), and it is nice to support other Unix-like systems if you want -to. Supporting a variety of Unix-like systems is desirable, although -not paramount. It is usually not too hard, so you may as well do it. -But you don't have to consider it an obligation, if it does turn out to -be hard. +(for example free BSD variants), and it is nice to support other +Unix-like systems if you want to. Supporting a variety of Unix-like +systems is desirable, although not paramount. It is usually not too +hard, so you may as well do it. But you don't have to consider it an +obligation, if it does turn out to be hard. @pindex autoconf The easiest way to achieve portability to most Unix-like systems is to
Re: Cygwin && WIN32
Bruno Haible <[EMAIL PROTECTED]> writes: > Paul Eggert wrote: >> > In other places I used to define WIN32 as an abbreviation of >> > defined _WIN32 || defined __WIN32__ >> > Now I'm renaming that to WIN32_NATIVE. >> >> Would WOE32_NATIVE be a better name? > > Many people believe code should be neutral. How about W32_NATIVE then? I believe that some other GNU code uses w32 as a "32-bit Windows" prefix. -- "In this world that Hugh Heffner had made, he alone seemed forever bunnyless." --John D. MacDonald
Re: getloadavg module broken
Jim Meyering wrote: > That is because it's looking in the wrong place. > This patch fixes the immediate problem Indeed, thanks. But the bug is really in the AC_FUNC_GETLOADAVG macro in autoconf. The macros AC_FUNC_ERROR_AT_LINE, AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK, AC_FUNC_MALLOC, AC_FUNC_MEMCMP, AC_FUNC_MKTIME, AC_FUNC_OBSTACK, AC_FUNC_REALLOC, AC_FUNC_STRTOD, AC_FUNC_STRNLEN, AC_REPLACE_FNMATCH are all able to call AC_LIBOBJ without additional hassles on the user. AC_FUNC_GETLOADAVG is not. I'd ask to remove these lines from the AC_FUNC_GETLOADAVG macro: - # Make sure getloadavg.c is where it belongs, at configure-time. test -f "$srcdir/$ac_config_libobj_dir/getloadavg.c" || AC_MSG_ERROR([$srcdir/$ac_config_libobj_dir/getloadavg.c is missing]) - and to change AC_FUNC_GETLOADAVG so that it doesn't need to #include this file at configure time. Rationale: It's not autoconf's business to impose file name restrictions on a project, nor to check file names at configure time. "configure" is there to test a platform's and compiler's feature. Checking a project's files integrity is the job of automake. > may cause trouble for people who put the libobj directory elsewhere. > If any of you know of such a package, please let me know. There are many such packages: - gettext: both libgrep and lib (not just one directory). - libiconv: srclib. - libtasn1: gl - m4: gnu - gpg: gl - libksba: gl - prelude: libmissing ... I can hack gnulib-tool to override AC_LIBOBJ and AC_REPLACE_FUNCS so that it works with two different directories with .c files, but no workaround is possible against hardcoded file checks in autoconf macros. Bruno
Re: standards.texi language cleanup (was: Cygwin && WIN32)
Hi Ralf, * doc/standards.texi (System Portability): Spell out `free BSD variants', instead of using the term `*BSD'. Before I bother rms with this, can you please explain to me the objection to "*BSD"? I'd never heard that before. NetBSD and OpenBSD don't like being lumped together? Thanks, karl
Re: [bug-gnulib] Re: nanosleep module and mingw32
Bruno Haible <[EMAIL PROTECTED]> writes:
> Since gnulib's policy is to let the programs write code in POSIX
> syntax, I vote for a module that creates a file in
> the build directory.
Yes, that would make sense, to properly declare 'select'. For
nanosleep I suppose we'd also need a substitute time.h that declares
nanosleep.
There's one other thing about this particular problem that may save us
here, though. The current code tests that nanosleep works at runtime,
not merely whether it links. I suspect this is overkill, at least
nowadays. And, since the original poster is talking about a
cross-compilation environment, where all runtime tests fail, maybe
changing the test to check only that nanosleep links will solve his
problem, as the replacement code won't be compiled at all.
I installed the following patch along these lines. If it doesn't
suffice (or maybe even if it does) we can continue along the
header-replacement route.
2006-05-19 Paul Eggert <[EMAIL PROTECTED]>
* nanosleep.c [HAVE_SYS_SELECT_H]: Include .
Use the usual Autoconf way to include and/or sys/time.h.
(my_usleep): Don't mishandle maximum value.
* m4/nanosleep.m4 (gl_FUNC_NANOSLEEP): Rename cache variables to use
gl_ rather than jm_. Link, don't run, so that cross-compiles are
allowed. Check that resulting type is arithmetic.
Check for sys/select.h.
--- lib/nanosleep.c 23 Sep 2005 04:15:13 - 1.17
+++ lib/nanosleep.c 19 May 2006 17:45:21 -
@@ -1,5 +1,7 @@
/* Provide a replacement for the POSIX nanosleep function.
- Copyright (C) 1999, 2000, 2002, 2004, 2005 Free Software Foundation, Inc.
+
+ Copyright (C) 1999, 2000, 2002, 2004, 2005, 2006 Free Software
+ Foundation, Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -27,9 +29,23 @@
#include
#include
+#if HAVE_SYS_SELECT_H
+# include
+#endif
#include
#include
+#if TIME_WITH_SYS_TIME
+# include
+# include
+#else
+# if HAVE_SYS_TIME_H
+# include
+# else
+# include
+# endif
+#endif
+
#include
#include
@@ -57,7 +73,7 @@ sighandler (int sig)
suspended = 1;
}
-/* FIXME: comment */
+/* Suspend execution for at least *TS_DELAY seconds. */
static void
my_usleep (const struct timespec *ts_delay)
@@ -67,13 +83,20 @@ my_usleep (const struct timespec *ts_del
tv_delay.tv_usec = (ts_delay->tv_nsec + 999) / 1000;
if (tv_delay.tv_usec == 100)
{
- tv_delay.tv_sec++;
- tv_delay.tv_usec = 0;
+ time_t t1 = tv_delay.tv_sec + 1;
+ if (t1 < tv_delay.tv_sec)
+ tv_delay.tv_usec = 100 - 1; /* close enough */
+ else
+ {
+ tv_delay.tv_sec = t1;
+ tv_delay.tv_usec = 0;
+ }
}
select (0, NULL, NULL, NULL, &tv_delay);
}
-/* FIXME: comment */
+/* Suspend execution for at least *REQUESTED_DELAY seconds. The
+ *REMAINING_DELAY part isn't implemented yet. */
int
rpl_nanosleep (const struct timespec *requested_delay,
--- m4/nanosleep.m4 24 Apr 2006 07:35:24 - 1.23
+++ m4/nanosleep.m4 19 May 2006 17:45:24 -
@@ -1,4 +1,4 @@
-#serial 16
+#serial 17
dnl From Jim Meyering.
dnl Check for the nanosleep function.
@@ -16,6 +16,12 @@ AC_DEFUN([gl_FUNC_NANOSLEEP],
[
AC_LIBSOURCES([nanosleep.c])
+ dnl Persuade glibc and Solaris to declare nanosleep.
+ AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
+
+ AC_REQUIRE([AC_HEADER_TIME])
+ AC_CHECK_HEADERS_ONCE(sys/time.h)
+
nanosleep_save_libs=$LIBS
# Solaris 2.5.1 needs -lposix4 to get the nanosleep function.
@@ -25,15 +31,10 @@ AC_DEFUN([gl_FUNC_NANOSLEEP],
LIB_NANOSLEEP=$ac_cv_search_nanosleep])
AC_SUBST([LIB_NANOSLEEP])
- AC_CACHE_CHECK([whether nanosleep works],
- jm_cv_func_nanosleep_works,
+ AC_CACHE_CHECK([for nanosleep],
+ [gl_cv_func_nanosleep],
[
- dnl Persuade glibc and Solaris to declare nanosleep.
- AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
-
- AC_REQUIRE([AC_HEADER_TIME])
- AC_CHECK_HEADERS_ONCE(sys/time.h)
- AC_TRY_RUN([
+ AC_LINK_IFELSE([AC_LANG_SOURCE([[
# if TIME_WITH_SYS_TIME
#include
#include
@@ -51,15 +52,13 @@ AC_DEFUN([gl_FUNC_NANOSLEEP],
struct timespec ts_sleep, ts_remaining;
ts_sleep.tv_sec = 0;
ts_sleep.tv_nsec = 1;
- return nanosleep (&ts_sleep, &ts_remaining) != 0;
+ return nanosleep (&ts_sleep, &ts_remaining) < 0;
}
- ],
-jm_cv_func_nanosleep_works=yes,
-jm_cv_func_nanosleep_works=no,
-dnl When crosscompiling, assume the worst.
-jm_cv_func_nanosleep_works=no)
+ ]])],
+ [gl_cv_func_nanosleep=yes],
+ [gl_cv_func_nanosleep=no])
])
- if test $jm_cv_func_nanosleep_works = no; then
+ if test $gl_cv_func_nanosleep = no; then
AC_LIBOBJ(nanosleep)
AC_DEFINE(nanosleep, rpl_nanosleep,
[Define to rpl_nanosleep if the replacement function should be used.])
@@
Re: standards.texi language cleanup
Hi Karl, * Karl Berry wrote on Fri, May 19, 2006 at 07:19:41PM CEST: > > * doc/standards.texi (System Portability): Spell out `free BSD > variants', instead of using the term `*BSD'. > > Before I bother rms with this, can you please explain to me the > objection to "*BSD"? AFAIR it alludes to controversies between the BSD camps. No, I don't have a public source for this, I'd have to ask (should I?). I thought this was more commonly known (with me being the exception that didn't know) or seen that way. If that's not the case, I'm unsure if it's worth bothering. Cheers, Ralf
Re: Cygwin && WIN32
>>> Would WOE32_NATIVE be a better name? >> >> Many people believe code should be neutral. OK, but WIN32_NATIVE isn't neutral either; it connotes "win". > How about W32_NATIVE then? I believe that some other GNU code > uses w32 as a "32-bit Windows" prefix. That'd be OK.
a press article about gnulib
gnulib is getting exposed to a larger audience: http://www.linux.com/article.pl?sid=05/12/16/2051201 Nicely written article, IMO. Bruno
Re: [bug-gnulib] Re: standards.texi language cleanup (was: Cygwin && WIN32)
Karl Berry wrote: > * doc/standards.texi (System Portability): Spell out `free BSD > variants', instead of using the term `*BSD'. > > Before I bother rms with this, can you please explain to me the > objection to "*BSD"? I'd never heard that before. NetBSD and OpenBSD > don't like being lumped together? I think the "*" wildcard is usually neutral, but sometimes also used to abbreviate a word that one wouldn't like to pronounce. E.g. p*rl ... Bruno
Re: a press article about gnulib
Bruno Haible <[EMAIL PROTECTED]> writes: >http://www.linux.com/article.pl?sid=05/12/16/2051201 > > Nicely written article, IMO. Yes, it's unusual to have a reporter do that good a job. I did have a beef with the conclusion "you should not use it [gnulib] in critical software". "cp" isn't critical? I submitted a followup comment along those lines.
Re: standards.texi language cleanup
I thought this was more commonly known Not by me. I'm unsure if it's worth bothering. As always, I'd rather not occupy rms' time if we can avoid it. In the absence of any clamor to make this tiny change in the GNU standards.texi, I'd rather skip it. Thanks, karl
[EMAIL PROTECTED]: GNU Coding Standards, internatialisation and plurals]
Seeking advice ... my response follows.
Date: Sun, 14 May 2006 15:47:08 +0200
From: "Michael Thayer" <[EMAIL PROTECTED]>
To: bug-standards@gnu.org
Subject: GNU Coding Standards, internatialisation and plurals
Hello,
I would like to point out a problem with your advise on writing
strings in programmes for internationalisation. To enable translators
to deal with plurals correctly, you recommend using the following
style:
(quote)
printf ((nfiles != 1 ? "%d files processed"
: "%d file processed"),
nfiles);
(unquote)
This has the problem that not all languages treat singular and plural
the same way as English. For example, Arabic uses singular, dual and
plural rather than just singular and plural. Russian uses a different
case depending on whether the number ends in 1, in 2-4 or in 5-9, 0 or
11-19. And I believe many languages treat zero as singular (although
it is probably better to have a sentence like "No files processed" for
zero). Newer versions of Gettext take these things into account.
Another thing worth mentioning is that it is better to limit strings
to be translated to one number argument per sentence unit (i.e.
"Searched %d directories. Found %d files" or "Searched %d
directories and found %d files" rather than "Found %d files in %d
directories") as some languages may prefer to express the arguments in
reverse order ("In %d directories found %d files"), which printf would
probably not take kindly to.
Kind regards,
Michael
Re: GNU Coding Standards, internatialisation and plurals
Hi Michael, Thanks for writing. This has the problem that not all languages treat singular and plural the same way as English. I see the problem, but what is the solution? Repeating every message containing a number to have separate cases for so many integers seems quite impractical. Cc-ing gnulib friends for their input ... Another thing worth mentioning is that it is better to limit strings to be translated to one number argument per sentence unit A good point, thanks. I can see the advice being hard to follow in practice, though, since "found %d files in %d directories" is such a natural expression in English. Fortunately I don't think it comes up *too* often. Best regards, Karl
Re: [EMAIL PROTECTED]: GNU Coding Standards, internatialisation and plurals]
[EMAIL PROTECTED] (Karl Berry) writes:
> printf ((nfiles != 1 ? "%d files processed"
> : "%d file processed"),
> nfiles);
>
> (unquote)
>
> This has the problem that not all languages treat singular and plural
> the same way as English.
It might be helpful to recommend diagnostics that don't use singular
or plural at all, e.g.:
printf ("Files processed: %d", nfiles);
This is equally awkward in almost all languages (:-), and bypasses the
singular/plural/etc. mess.
Another possibility is to update the recommendation to match the state
of the latest gettext. (To be honest, I don't know what that is.)
We could do both, too.
> Another thing worth mentioning is that it is better to limit strings
> to be translated to one number argument per sentence unit (i.e.
> "Searched %d directories. Found %d files" or "Searched %d
> directories and found %d files" rather than "Found %d files in %d
> directories") as some languages may prefer to express the arguments in
> reverse order ("In %d directories found %d files"), which printf would
> probably not take kindly to.
This point doesn't make sense to me. First, the translation need not
use the same number of sentences as the original. Second,
translations generally can assume the %$n notation, which lets the
translator reorder the arguments.
Re: [EMAIL PROTECTED]: GNU Coding Standards, internatialisation and plurals]
Karl Berry wrote:
Another thing worth mentioning is that it is better to limit strings
to be translated to one number argument per sentence unit (i.e.
"Searched %d directories. Found %d files" or "Searched %d
directories and found %d files" rather than "Found %d files in %d
directories") as some languages may prefer to express the arguments in
reverse order ("In %d directories found %d files"), which printf would
probably not take kindly to.
Actually, in reasonably recent versions of printf, this is handled
via "... %2$d ... %1$d...". That syntax was added specifically for
this issue. printf libraries that do not support this are now very
old. If you care about such systems, there are add-on libraries about
that you can include with your project sources that handle this
correctly.
Cheers - Bruce
