_GL_CXXALIAS_SYS (raise, int, (int sig)); in signal.h may give complie error in C++ source.
In the bug tracker octave, in which gnulib components are used, _GL_CXXALIAS_SYS (raise, int, (int sig)); in signal.h seems to give compile error. https://savannah.gnu.org/bugs/?34378 John W. Eaton said in comment #3 in the above tracker that * I'm fairly sure this is a bug in gnulib, so needs to be fixed there. There shouldn't be two _GL_CXXALIAS_SYS (raise, int, (int sig)); lines in the libgnu/signal.h file, or if there are, they should be fixed so that they don't conflict. But in any case, that's something for the gnulib developers to fix. * I have comment out one of _GL_CXXALIAS_SYS (raise, int, (int sig)); lines compile error was disappeared. Regards Tatsuro
gengetopt, anyone?
I've just been playing with gengetopt. There's a lot to like: it gives me (potentially multi-language) options handling for one line per option (plus any extra text I want) in a simple .ggo file, and half a dozen lines of code (four of which really should be redundant as they test the help and version flags and call the relevant display routine). All the necessary variables to signal which options are set and their values are defined for me. The only thing really not to like is that for my simple six-option program it generates 565 lines of C. My program is only 140 lines, representing a roughly 500-line net addition when I use gengetopt. I'm not inclined to worry that much, but it does seem a lot. There's also a slew of minor issues, mostly cosmetic, and all easy to fix, for which I've filed a dizaine of bug reports and offered to fix myself. It should not go unremarked that gengetopt is big on gnulib (though one of the bugs I filed is that its manual overenthusiastically documents how to add gnulib to a project!). Has anyone else any experience with it? It would seem to have applications in, for example, coreutils, though its use would obviously be a fair amount of work and the quantity of code it generates might be more of a concern. -- http://rrt.sc3d.org
Re: gengetopt, anyone?
Reuben Thomas wrote: I've just been playing with gengetopt. There's a lot to like: it gives me (potentially multi-language) options handling for one line per option (plus any extra text I want) in a simple .ggo file, and half a dozen lines of code (four of which really should be redundant as they test the help and version flags and call the relevant display routine). All the necessary variables to signal which options are set and their values are defined for me. The only thing really not to like is that for my simple six-option program it generates 565 lines of C. My program is only 140 lines, representing a roughly 500-line net addition when I use gengetopt. I'm not inclined to worry that much, but it does seem a lot. There's also a slew of minor issues, mostly cosmetic, and all easy to fix, for which I've filed a dizaine of bug reports and offered to fix myself. It should not go unremarked that gengetopt is big on gnulib (though one of the bugs I filed is that its manual overenthusiastically documents how to add gnulib to a project!). Has anyone else any experience with it? It would seem to have applications in, for example, coreutils, though its use would obviously be a fair amount of work and the quantity of code it generates might be more of a concern. Hi Reuben, a fair amount? British understatement, surely ;-) I suspect that you'll find many exceptions. If we were starting coreutils development now, I'd be much more inclined to use it, but it seems like the minimal benefit from that sort of large-scale factorization would not be worth the effort. [not even considering code size issues]
Re: gengetopt, anyone?
Reuben Thomas r...@sc3d.org writes: Has anyone else any experience with it? I have used it in libidn, gsasl and a few other projects since well over 5 years. I have been quite happy with it. The biggest concern I have had is that the auto-generated --help screen is impossible to fine-tune and it doesn't look as good as I want it to. For Libidn, I have given up on using the auto-generated --help output and instead wrote a custom function for displaying it. For gsasl I still use the auto-generated screen, mostly due to the much larger amount of parameters. One of the things I want to go away is that it prints the project name and version as the first line of --help, I think there is no point in having that there (there is --version after all) and I would prefer a terse Usage:-line instead. /Simon
Re: gengetopt, anyone?
On 27 September 2011 14:49, Simon Josefsson si...@josefsson.org wrote: The biggest concern I have had is that the auto-generated --help screen is impossible to fine-tune and it doesn't look as good as I want it to. Most of the bugs I have filed and offered to fix are precisely to do with making the details of the help display match coreutils grep better. -- http://rrt.sc3d.org
Re: [sshfs] bug#6331: df reports wrong disk space usage on solaris
Jim, Any news about this bug? This problem was again reported against a recent Debian release here: http://article.gmane.org/gmane.comp.file-systems.fuse.sshfs/1200 Thanks, Miklos
Re: gengetopt, anyone?
On 09/27/11 06:49, Simon Josefsson wrote: Reuben Thomasr...@sc3d.org writes: Has anyone else any experience with it? I have used it in libidn, gsasl and a few other projects since well over 5 years. I have been quite happy with it. The biggest concern I have had is that the auto-generated --help screen is impossible to fine-tune and it doesn't look as good as I want it to. For Libidn, I have given up on using the auto-generated --help output and instead wrote a custom function for displaying it. For gsasl I still use the auto-generated screen, mostly due to the much larger amount of parameters. One of the things I want to go away is that it prints the project name and version as the first line of --help, I think there is no point in having that there (there is --version after all) and I would prefer a terse Usage:-line instead. I have also played with it, and tried to combine my autoopts strengths with Lorenzo, but he seemed pointedly uninterested. In the end, there is little gengetopt does that is not well covered by autoopts: http://www.gnu.org/software/autogen/compare.html and it is more easily covered in autoopts. WRT fair amount of work, I'd have to agree with Jim. It is an understatement. The problem being that since each program basically parses its own options (getopt() and getopt_long() being only very minor assists), and has non-standard-isms in the way they are handled. You'd have to go back to the generator engine and add a lot of exceptional handling code. Not worth it. BTW, current NTP code uses autoopts for handling its options and configuration files and multi-flavored man pages. Cheers - Bruce
Re: getline vs linebuffer
On 26 September 2011 23:24, Eric Blake ebl...@redhat.com wrote: So _both_ linebuffer and getdelim would benefit from a conversion to freadptr. I just tried using getndelim2 instead of getline for a program which slurps text line by line but spends most of its time regexp-searching the text, and it made no detectable difference, so I guess it really does have to be hardcore slurping. Is there some reason that getline getdelim can't just be wrappers to getndelim2? -- http://rrt.sc3d.org
Re: getline vs linebuffer
On 27 September 2011 22:45, Reuben Thomas r...@sc3d.org wrote: On 26 September 2011 23:24, Eric Blake ebl...@redhat.com wrote: So _both_ linebuffer and getdelim would benefit from a conversion to freadptr. I just tried using getndelim2 instead of getline for a program which slurps text line by line but spends most of its time regexp-searching the text, and it made no detectable difference, so I guess it really does have to be hardcore slurping. Or perhaps glibc's getline is efficient? -- http://rrt.sc3d.org
Re: getline vs linebuffer
On 09/27/2011 11:12 PM, Reuben Thomas wrote: On 27 September 2011 22:45, Reuben Thomas r...@sc3d.org wrote: On 26 September 2011 23:24, Eric Blake ebl...@redhat.com wrote: So _both_ linebuffer and getdelim would benefit from a conversion to freadptr. I just tried using getndelim2 instead of getline for a program which slurps text line by line but spends most of its time regexp-searching the text, and it made no detectable difference, so I guess it really does have to be hardcore slurping. Or perhaps glibc's getline is efficient? I found it very efficient http://www.pixelbeat.org/programming/readline/ Note when testing io functions ensure that gnulib/lib/unlocked-io.h is used appropriately, especially for getc using functions like getndelim2() I previously did an itemization of the line processing in coreutils: http://lists.gnu.org/archive/html/bug-coreutils/2009-03/msg00116.html cheers, Pádraig.
Re: getline vs linebuffer
2011/9/27 Pádraig Brady p...@draigbrady.com: On 09/27/2011 11:12 PM, Reuben Thomas wrote: Note when testing io functions ensure that gnulib/lib/unlocked-io.h is used appropriately, especially for getc using functions like getndelim2() The point Eric was making is that getndelim2 doesn't use getc (if it can help it) any more. -- http://rrt.sc3d.org
Re: _GL_CXXALIAS_SYS (raise, int, (int sig)); in signal.h may give complie error in C++ source.
Hi,
Tatsuro MATSUOKA wrote:
In the bug tracker octave, in which gnulib components are used,
_GL_CXXALIAS_SYS (raise, int, (int sig)); in signal.h seems to give compile
error.
https://savannah.gnu.org/bugs/?34378
John W. Eaton said in comment #3 in the above tracker that
*
I'm fairly sure this is a bug in gnulib, so needs to be fixed there. There
shouldn't be two
_GL_CXXALIAS_SYS (raise, int, (int sig));
lines in the libgnu/signal.h file
Thanks for the report. Yes, obviously this a mistake that I introduced on
2011-09-23. This patch fixes it:
2011-09-26 Bruno Haible br...@clisp.org
raise: Fix double declaration with modules 'sigprocmask' and 'sigpipe'.
* lib/signal.in.h (GNULIB_defined_signal_blocking): New macro.
(raise): Remove older, duplicated declaration.
(_gl_raise_SIGPIPE): New declaration.
* lib/sigprocmask.c (_gl_raise_SIGPIPE): New function.
(rpl_raise): Remove function.
* lib/raise.c (rpl_raise, raise): Merge into a single function. Handle
a gnulib-defined SIGPIPE here.
* m4/raise.m4 (gl_FUNC_RAISE): Set REPLACE_RAISE also if the module
'sigprocmask' has detected missing signal-blocking and the module
'sigpipe' is enabled.
Reported by Tatsuro MATSUOKA tmaccha...@yahoo.co.jp.
--- lib/raise.c.origWed Sep 28 00:43:41 2011
+++ lib/raise.c Tue Sep 27 22:15:23 2011
@@ -50,24 +50,30 @@
return result;
}
-# define raise raise_nothrow
+# else
+# define raise_nothrow raise
# endif
-int
-rpl_raise (int sig)
-{
- return raise_nothrow (sig);
-}
-
#else
/* An old Unix platform. */
# include unistd.h
+# define rpl_raise raise
+
+#endif
+
int
-raise (int sig)
+rpl_raise (int sig)
{
- return kill (getpid (), sig);
-}
+#if GNULIB_defined_signal_blocking GNULIB_defined_SIGPIPE
+ if (sig == SIGPIPE)
+return _gl_raise_SIGPIPE ();
+#endif
+#if HAVE_RAISE
+ return raise_nothrow (sig);
+#else
+ return kill (getpid (), sig);
#endif
+}
--- lib/signal.in.h.origWed Sep 28 00:43:42 2011
+++ lib/signal.in.h Tue Sep 27 22:09:27 2011
@@ -178,6 +178,10 @@
#if @GNULIB_SIGPROCMASK@
# if !@HAVE_POSIX_SIGNALBLOCKING@
+# ifndef GNULIB_defined_signal_blocking
+# define GNULIB_defined_signal_blocking 1
+# endif
+
/* Maximum signal number + 1. */
# ifndef NSIG
# define NSIG 32
@@ -303,18 +307,10 @@
# endif
_GL_CXXALIASWARN (signal);
-/* Raise signal SIG. */
# if !@HAVE_POSIX_SIGNALBLOCKING@ GNULIB_defined_SIGPIPE
-# if !(defined __cplusplus defined GNULIB_NAMESPACE)
-# undef raise
-# define raise rpl_raise
-# endif
-_GL_FUNCDECL_RPL (raise, int, (int sig));
-_GL_CXXALIAS_RPL (raise, int, (int sig));
-# else
-_GL_CXXALIAS_SYS (raise, int, (int sig));
+/* Raise signal SIGPIPE. */
+_GL_EXTERN_C int _gl_raise_SIGPIPE (void);
# endif
-_GL_CXXALIASWARN (raise);
#elif defined GNULIB_POSIXCHECK
# undef sigaddset
--- lib/sigprocmask.c.orig Wed Sep 28 00:43:42 2011
+++ lib/sigprocmask.c Tue Sep 27 21:54:35 2011
@@ -330,27 +330,19 @@
}
#if GNULIB_defined_SIGPIPE
-/* Raise the signal SIG. */
+/* Raise the signal SIGPIPE. */
int
-rpl_raise (int sig)
-# undef raise
+_gl_raise_SIGPIPE (void)
{
- switch (sig)
+ if (blocked_set (1U SIGPIPE))
+pending_array[SIGPIPE] = 1;
+ else
{
-case SIGPIPE:
- if (blocked_set (1U sig))
-pending_array[sig] = 1;
- else
-{
- handler_t handler = SIGPIPE_handler;
- if (handler == SIG_DFL)
-exit (128 + SIGPIPE);
- else if (handler != SIG_IGN)
-(*handler) (sig);
-}
- return 0;
-default: /* System defined signal */
- return raise (sig);
+ handler_t handler = SIGPIPE_handler;
+ if (handler == SIG_DFL)
+exit (128 + SIGPIPE);
+ else if (handler != SIG_IGN)
+(*handler) (SIGPIPE);
}
}
#endif
--- m4/raise.m4.origWed Sep 28 00:43:42 2011
+++ m4/raise.m4 Tue Sep 27 22:03:30 2011
@@ -1,4 +1,4 @@
-# raise.m4 serial 1
+# raise.m4 serial 2
dnl Copyright (C) 2011 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -16,6 +16,17 @@
if test $HAVE_MSVC_INVALID_PARAMETER_HANDLER = 1; then
REPLACE_RAISE=1
fi
+m4_ifdef([gl_SIGNALBLOCKING], [
+ gl_SIGNALBLOCKING
+ if test $HAVE_POSIX_SIGNALBLOCKING = 0; then
+m4_ifdef([gl_SIGNAL_SIGPIPE], [
+ gl_SIGNAL_SIGPIPE
+ if test $gl_cv_header_signal_h_SIGPIPE != yes; then
+REPLACE_RAISE=1
+ fi
+], [:])
+ fi
+])
fi
])
--
In memoriam Paul Eppstein http://de.wikipedia.org/wiki/Paul_Eppstein
Re: msvc-inval: more options
FAIL: test-fgetc.exe
FAIL: test-fputc.exe
FAIL: test-fread.exe
FAIL: test-fwrite.exe
All these fail on a stream whose file descriptor has been closed. Most
libraries won't do such a thing. Therefore I don't find it worth to fix
this. Just document it.
But two of the tests still fail, and the other two succeed only accidentally.
This patch makes the 4 tests pass:
2011-09-26 Bruno Haible br...@clisp.org
fputc, fwrite tests: Avoid test failure on MSVC.
* tests/test-fgetc.c: Include msvc-inval.h.
(main): Invoke gl_msvc_inval_ensure_handler.
* tests/test-fputc.c: Include msvc-inval.h.
(main): Invoke gl_msvc_inval_ensure_handler.
* tests/test-fread.c: Include msvc-inval.h.
(main): Invoke gl_msvc_inval_ensure_handler.
* tests/test-fwrite.c: Include msvc-inval.h.
(main): Invoke gl_msvc_inval_ensure_handler.
* modules/fgetc-tests (Depends-on): Add msvc-inval.
* modules/fputc-tests (Depends-on): Likewise.
* modules/fread-tests (Depends-on): Likewise.
* modules/fwrite-tests (Depends-on): Likewise.
--- modules/fgetc-tests.origWed Sep 28 01:57:30 2011
+++ modules/fgetc-tests Wed Sep 28 01:56:31 2011
@@ -6,6 +6,7 @@
Depends-on:
unistd
fdopen
+msvc-inval
configure.ac:
--- modules/fputc-tests.origWed Sep 28 01:57:30 2011
+++ modules/fputc-tests Wed Sep 28 01:56:42 2011
@@ -6,6 +6,7 @@
Depends-on:
unistd
fdopen
+msvc-inval
configure.ac:
--- modules/fread-tests.origWed Sep 28 01:57:30 2011
+++ modules/fread-tests Wed Sep 28 01:56:53 2011
@@ -6,6 +6,7 @@
Depends-on:
unistd
fdopen
+msvc-inval
configure.ac:
--- modules/fwrite-tests.orig Wed Sep 28 01:57:30 2011
+++ modules/fwrite-testsWed Sep 28 01:57:05 2011
@@ -6,6 +6,7 @@
Depends-on:
unistd
fdopen
+msvc-inval
configure.ac:
--- tests/test-fgetc.c.orig Wed Sep 28 01:57:30 2011
+++ tests/test-fgetc.c Wed Sep 28 01:52:33 2011
@@ -26,6 +26,8 @@
#include fcntl.h
#include unistd.h
+#include msvc-inval.h
+
#include macros.h
int
@@ -33,6 +35,12 @@
{
const char *filename = test-fgetc.txt;
+ /* We don't have an fread() function that installs an invalid parameter
+ handler so far. So install that handler here, explicitly. */
+#if MSVC_INVALID_PARAMETER_HANDLING == DEFAULT_HANDLING
+ gl_msvc_inval_ensure_handler ();
+#endif
+
/* Prepare a file. */
{
const char text[] = hello world;
--- tests/test-fputc.c.orig Wed Sep 28 01:57:30 2011
+++ tests/test-fputc.c Wed Sep 28 01:52:34 2011
@@ -26,6 +26,8 @@
#include fcntl.h
#include unistd.h
+#include msvc-inval.h
+
#include macros.h
int
@@ -33,6 +35,12 @@
{
const char *filename = test-fputc.txt;
+ /* We don't have an fputc() function that installs an invalid parameter
+ handler so far. So install that handler here, explicitly. */
+#if MSVC_INVALID_PARAMETER_HANDLING == DEFAULT_HANDLING
+ gl_msvc_inval_ensure_handler ();
+#endif
+
/* Test that fputc() on an unbuffered stream sets errno if someone else
closes the stream fd behind the back of stdio. */
{
--- tests/test-fread.c.orig Wed Sep 28 01:57:30 2011
+++ tests/test-fread.c Wed Sep 28 01:52:33 2011
@@ -26,6 +26,8 @@
#include fcntl.h
#include unistd.h
+#include msvc-inval.h
+
#include macros.h
int
@@ -33,6 +35,12 @@
{
const char *filename = test-fread.txt;
+ /* We don't have an fread() function that installs an invalid parameter
+ handler so far. So install that handler here, explicitly. */
+#if MSVC_INVALID_PARAMETER_HANDLING == DEFAULT_HANDLING
+ gl_msvc_inval_ensure_handler ();
+#endif
+
/* Prepare a file. */
{
const char text[] = hello world;
--- tests/test-fwrite.c.origWed Sep 28 01:57:30 2011
+++ tests/test-fwrite.c Wed Sep 28 01:52:34 2011
@@ -26,6 +26,8 @@
#include fcntl.h
#include unistd.h
+#include msvc-inval.h
+
#include macros.h
int
@@ -33,6 +35,12 @@
{
const char *filename = test-fwrite.txt;
+ /* We don't have an fwrite() function that installs an invalid parameter
+ handler so far. So install that handler here, explicitly. */
+#if MSVC_INVALID_PARAMETER_HANDLING == DEFAULT_HANDLING
+ gl_msvc_inval_ensure_handler ();
+#endif
+
/* Test that fwrite() on an unbuffered stream sets errno if someone else
closes the stream fd behind the back of stdio. */
{
--
In memoriam Paul Eppstein http://de.wikipedia.org/wiki/Paul_Eppstein
