Re: overly zealous git hook

[Bruno Haible]

Hi Jim,

> > FYI, this change in behavior is the result of savannah upgrading to
> > the latest version of git, whose git diff --check tests for that.

Thanks for the pointer. Indeed, the relevant git changes are:
http://git.kernel.org/?p=git/git.git;a=commitdiff;h=877f23ccb88227203f2576abdfb5d1c15925fcb3
http://git.kernel.org/?p=git/git.git;a=commitdiff;h=04c6e9e9ca34226db095bbaa1218030f99f0b7c6

> Yes. These should be: modules/**/* and **/ChangeLog*. I believe it
> can be done by adding to .gitattributes a line
>   ChangeLog* whitespace=-
> and to modules/.gitattributes a line
>   * whitespace=-
> where  is the whitespace rule that triggers the error.

I'm adding modules/.gitattributes as follows:

===
# "git diff --check" should not reject modules files which end in a blank line.
* whitespace=-trail
===

But "git push" is now still rejected:

  modules/pipe-filter:34: ends with blank lines.
  error: hooks/update exited with error code 2
  error: hook declined to update refs/heads/master
  To ssh://hai...@git.sv.gnu.org/srv/git/gnulib
   ! [remote rejected] master -> master (hook declined)
  error: failed to push some refs to 
'ssh://hai...@git.sv.gnu.org/srv/git/gnulib'

Why does the "git diff --check" on the server side not take into account the
modules/.gitattributes?

Bruno

Re: overly zealous git hook

[Jim Meyering]

Bruno Haible wrote:

> Hi Jim,
>
>> Actually, I see trailing blank lines in any text file
>> as an opportunity for unexpected merge conflicts, as
>> one person adds or removes one of those oft-unnoticed lines,
>> and someone else makes a conflicting change.
>
> Conflicts generally occur at spots that are heavily modified,
> such as the end of log files or the start of ChangeLog files.
> For modules/* files, the last section is the 'Maintainer' section,
> which rarely changes. Likewise for the end of ChangeLog files:
> it does not change at all, usually.
>
>> FYI, this change in behavior is the result of savannah upgrading to
>> the latest version of git, whose git diff --check tests for that.
>
> Ah, understood.
>
>> Since I prefer that the hook continue to apply to all files
>> for which I have a say, perhaps you'd like to itemize the files
>> for which you want to allow trailing blank lines?
>
> Yes. These should be: modules/**/* and **/ChangeLog*. I believe it

My point was that I'd like the existing hook to remain
in effect even for modules files.  If you want to make
exceptions for files you own, please itemize them so that
you do not disable that part of the hook for others.

Re: overly zealous git hook

[Jim Meyering]

Bruno Haible wrote:
> # "git diff --check" should not reject modules files which end in a blank 
> line.
> * whitespace=-trail
> ===
>
> But "git push" is now still rejected:
>
>   modules/pipe-filter:34: ends with blank lines.
>   error: hooks/update exited with error code 2
>   error: hook declined to update refs/heads/master
>   To ssh://hai...@git.sv.gnu.org/srv/git/gnulib
>! [remote rejected] master -> master (hook declined)
>   error: failed to push some refs to 
> 'ssh://hai...@git.sv.gnu.org/srv/git/gnulib'
>
> Why does the "git diff --check" on the server side not take into account the
> modules/.gitattributes?

The only exclusion I've made has been on the server side:

# cd /.../gnulib.git
# cat info/attributes
build-aux/texinfo.tex -whitespace

With a new-enough version of git, you can experiment/debug
by pushing to a local, test repository.

Re: [PATCH] lib/sha1.h: wrap declarations in extern "C" scope when included from C++

[Jim Meyering]

Peter Simons wrote:
>>From 640f2ed9570eef3189e43ec7550b32776fdebd0f Mon Sep 17 00:00:00 2001
> From: Peter Simons 
> Date: Sun, 19 Jul 2009 18:25:44 +0200
> Subject: [PATCH] lib/sha1.h: wrap declarations in extern "C" scope when 
> included from C++
>
> +#ifdef __cplusplus
> +extern "C" {
> +#endif

Hi Peter,

Would you please adjust that patch to do the same for all lib/sha*.h files
as well as lib/md5.h, and (if Simon agrees) lib/md[24].h?

Thanks,

Jim

Re: new module pipe-filter

[Paolo Bonzini]

On 07/20/2009 01:22 AM, Bruno Haible wrote:

Eric Blake wrote:

Such piping, where you write from the current process and read into
the current process, may hang on BSD systems, because some data is
present in system buffers but the system wants the buffers to be full
before it continues. A fix for this hang is to enable non-blocking I/O
and use a loop with select() that alternately reads and writes. See


Any chance of porting that over to gnulib?


I'm adding a new module 'pipe-filter', that does this.


I don't like very much the design of this module.  The problem is that 
it requires excessive effort on the child's part to buffer writes and/or 
to prepare all of the filter's input upfront.


A nicer interface IMHO could be:

/* Create a subprocess and pipe some data through it.
   progname is the program name used in error messages.
   prog_path is the file name of the program to invoke.
   prog_argv is a NULL terminated argument list, starting with
   prog_path as first element.
   If null_stderr is true, the subprocess' stderr will be redirected
   to /dev/null, and the usual error message to stderr will be
   omitted.  This is suitable when the subprocess does not fulfill an
   important task.
   If exit_on_error is true, any error will cause the main process to
   exit with an error status.
   If the subprocess does not start correctly, exit if exit_on_error is
   true, otherwise return NULL and set errno.

   The caller will write to the subprocess through filter_write; during
   calls to filter_write, the done_read function may be called to
   process any data that the subprocess has written.  done_read will
   receive at most read_bufsize bytes stored into buf, as well as a
   copy of private_data.  */

extern struct filter *
filter_create (const char *progname,
   const char *prog_path, char **prog_argv,
   bool null_stderr, bool exit_on_error,
   const char *buf, size_t read_bufsize,
   done_read_fn done_read,
   void *private_data);


/* Write size bytes starting at buf into the pipe and in the meanwhile
   possibly call the done_read function specified in create_filter.
   The done_read function may be called in a different thread than
   the current thread, depending on the platform.  However, it will
   always be called before filter_write has returned (or else will be
   delayed to the next call to filter_write or filter_close).  Return
   only after all the entire buffer has been written to the pipe.

   If there is a problem reading or writing, return -1 and set errno.
   If the subprocess exits early with nonzero status, return the status.
   (In either case, filter_write will instead exit if exit_on_error was
   passed as true).

   If the subprocess exits early with zero status, subsequent writes
   will becomes no-ops and zero is returned.

   Otherwise return 0.  */
extern int filter_write (struct filter *f,
 const char *buf, size_t size);

/* Finish reading the output via the done_read function specified in
   create_filter.  The done_read function may be called in a different
   thread than.  However, it will always be called before filter_close
   has returned.  The write side of the pipe is closed as soon as
   filter_close starts, while the read side will be closed just before
   it finishes.  If there is a problem reading or closing the pipe,
   return -1 and set errno.  If the subprocess exits early with nonzero
   status, return the status.  (In either case, filter_close will
   instead exit if exit_on_error was passed as true).

   Otherwise return 0.  */
extern int filter_close (struct filter *f);

Paolo

Re: dup2 on mingw

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Bruno Haible on 7/20/2009 6:00 PM:
> Eric Blake wrote:
>> On mingw, dup2 always returns 0 for success, rather than the fd just opened.
>> So I guess I'll start the process of writing a dup2 replacement module;
> 
> Yes, that's definitely a portability pitfall that warrants a wrapper module.

And in writing the testcase, I learned that cygwin 1.5 also has a bug, in
that dup2(1,1) returns 0 (but at least cygwin's dup2(1,2) returns 2).
Although you seldom see code using dup2 as a no-op for an fd onto itself,
it provides a great way to non-destructively check whether an fd is open
without having to use fcntl or _get_osfhandle (and so I did just that in
test-pipe.c).

I also noticed an unportable use of open, while using test-open.c as my
template for test-dup2.c.

Here's the patches I'm pushing.

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkplvYkACgkQ84KuGfSFAYAnQQCffBd+hN8NEHYO6T9RY2wEWEvf
Af8An33APaFX/hlkiR2N0UKtEva7A172
=Yv8J
-END PGP SIGNATURE-
>From ce186310c3af2ff05e80724f873fe37955a3a29a Mon Sep 17 00:00:00 2001
From: Eric Blake 
Date: Tue, 21 Jul 2009 06:48:26 -0600
Subject: [PATCH 1/2] dup2: work around mingw and cygwin 1.5 bug

* m4/dup2.m4 (gl_FUNC_DUP2): Detect mingw bug.
* m4/unistd_h.m4 (gl_UNISTD_H_DEFAULTS): Add witness.
* modules/unistd (Makefile.am): Substitute it.
* lib/unistd.in.h (dup2): Declare the replacement.
* lib/dup2.c (dup2) [REPLACE_DUP2]: Implement it.
* doc/posix-functions/dup2.texi (dup2): Document the bugs.
* lib/fchdir.c (rpl_dup2): Don't collide with mingw replacement.
* modules/execute (Depends-on): Add dup2.
* modules/fseterr (Depends-on): Likewise.
* modules/pipe (Depends-on): Likewise.
* modules/posix_spawn-internal (Depends-on): Likewise.

Signed-off-by: Eric Blake 
---
 ChangeLog |   15 +++
 doc/posix-functions/dup2.texi |8 
 lib/dup2.c|   29 +++--
 lib/fchdir.c  |7 ++-
 lib/unistd.in.h   |   11 ---
 m4/dup2.m4|   24 ++--
 m4/unistd_h.m4|3 ++-
 modules/execute   |1 +
 modules/fseterr   |1 +
 modules/pipe  |1 +
 modules/posix_spawn-internal  |1 +
 modules/unistd|1 +
 12 files changed, 89 insertions(+), 13 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 1b3d36c..18e1159 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,18 @@
+2009-07-21  Eric Blake  
+
+   dup2: work around mingw and cygwin 1.5 bug
+   * m4/dup2.m4 (gl_FUNC_DUP2): Detect mingw bug.
+   * m4/unistd_h.m4 (gl_UNISTD_H_DEFAULTS): Add witness.
+   * modules/unistd (Makefile.am): Substitute it.
+   * lib/unistd.in.h (dup2): Declare the replacement.
+   * lib/dup2.c (dup2) [REPLACE_DUP2]: Implement it.
+   * doc/posix-functions/dup2.texi (dup2): Document the bugs.
+   * lib/fchdir.c (rpl_dup2): Don't collide with mingw replacement.
+   * modules/execute (Depends-on): Add dup2.
+   * modules/fseterr (Depends-on): Likewise.
+   * modules/pipe (Depends-on): Likewise.
+   * modules/posix_spawn-internal (Depends-on): Likewise.
+
 2009-07-20  Bruno Haible  

* tests/test-pipe.c (BACKUP_STDERR_FILENO): New macro.
diff --git a/doc/posix-functions/dup2.texi b/doc/posix-functions/dup2.texi
index 42d22e5..bfaff38 100644
--- a/doc/posix-functions/dup2.texi
+++ b/doc/posix-functions/dup2.texi
@@ -9,6 +9,14 @@ Gnulib module: dup2
 Portability problems fixed by Gnulib:
 @itemize
 @item
+This function always returns 0 for success on some platforms:
+mingw.
+
+...@item
+This function returns 0 for dup2 (1, 1) on some platforms:
+Cygwin 1.5.x.
+
+...@item
 This function is missing on some older platforms.
 @end itemize

diff --git a/lib/dup2.c b/lib/dup2.c
index 0999082..e5d3de4 100644
--- a/lib/dup2.c
+++ b/lib/dup2.c
@@ -1,6 +1,7 @@
 /* Duplicate an open file descriptor to a specified file descriptor.

-   Copyright (C) 1999, 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
+   Copyright (C) 1999, 2004, 2005, 2006, 2007, 2009 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
@@ -25,7 +26,22 @@
 #include 
 #include 

-#ifndef F_DUPFD
+#if REPLACE_DUP2
+/* On mingw, dup2 exists, but always returns 0 for success.  */
+int
+dup2 (int fd, int desired_fd)
+#undef dup2
+{
+  int result = dup2 (fd, desired_fd);
+  if (result == 0)
+result = desired_fd;
+  return result;
+}
+
+#else /* !REPLACE_DUP2 */
+/* On older platforms, dup2 did not exist.  */
+
+# ifndef

Re: dup2 on mingw

[Eric Blake]

Eric Blake  byu.net> writes:

> > Yes, that's definitely a portability pitfall that warrants a wrapper module.
> 
> And in writing the testcase, I learned that cygwin 1.5 also has a bug, in
> that dup2(1,1) returns 0 (but at least cygwin's dup2(1,2) returns 2).
> Although you seldom see code using dup2 as a no-op for an fd onto itself,
> it provides a great way to non-destructively check whether an fd is open
> without having to use fcntl or _get_osfhandle (and so I did just that in
> test-pipe.c).

Well, it would be nice if doing that didn't hang mingw.  It looks like 
Microsoft has a bug, because using dup2(fd,fd) when fd is closed appears to 
deadlock the process.

I also botched the interaction between fchdir and dup2 (they can't both define 
rpl_dup2).

I'm working on a followup patch for both of these issues.

-- 
Eric Blake

Re: dup2 on mingw

[Eric Blake]

Eric Blake  byu.net> writes:

> Well, it would be nice if doing that didn't hang mingw.  It looks like 
> Microsoft has a bug, because using dup2(fd,fd) when fd is closed appears to 
> deadlock the process.

mingw also hangs on the second dup2 in dup2(fd,fd),dup2(fd,fd+1) if fd is open 
(meaning the first dup2, although it returned 0, manages to corrupt the state 
of fd).  In short, using equal fd is a recipe for disaster on mingw (which is 
probably why Linux chose for dup3 to return EINVAL in that case).

In thinking about things, should we try and treat the w32 concept of 
O_NOINHERIT like the Unix concept of FD_CLOEXEC?  If so, then it might be worth 
implementing Linux's dup3, and making w32spawn.h's dup_noinherit be synonymous 
with a call to dup3(fd, target, FD_CLOEXEC).  And to some degree, we almost 
have enough pieces in place to provide a semi-decent rpl_fcntl for mingw.  Of 
course, without O_CLOEXEC support, any rpl_dup3 replacement would be racy, but 
it at least provides convenience for code that is thinking about cloexec issues 
for when the OS catches up.  And at least dup3, like dup2, does not need a 
*_safer variant.

At any rate, here's the patch that gets mingw through the testsuite without 
hanging:


From: Eric Blake 
Date: Tue, 21 Jul 2009 09:00:57 -0600
Subject: [PATCH] dup2: fix more mingw problems

* lib/dup2.c (rpl_dup2) [_WIN32]: Avoid hanging when duplicating
fd to itself.
* doc/posix-functions/dup2.texi (dup2): Document the bug.
* lib/unistd.in.h (dup2) [REPLACE_FCHDIR]: Avoid name collision.
* lib/fchdir.c (dup2): Manage preprocessor macros correctly.
(rpl_dup2_fchdir): Rename from rpl_dup2, and let dup2 module take
care of mingw bugs.

Signed-off-by: Eric Blake 
---
 ChangeLog |9 +
 doc/posix-functions/dup2.texi |4 
 lib/dup2.c|   31 +++
 lib/fchdir.c  |   17 +
 lib/unistd.in.h   |8 +---
 5 files changed, 54 insertions(+), 15 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 6a89b40..2ede9ad 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,14 @@
 2009-07-21  Eric Blake  

+   dup2: fix more mingw problems
+   * lib/dup2.c (rpl_dup2) [_WIN32]: Avoid hanging when duplicating
+   fd to itself.
+   * doc/posix-functions/dup2.texi (dup2): Document the bug.
+   * lib/unistd.in.h (dup2) [REPLACE_FCHDIR]: Avoid name collision.
+   * lib/fchdir.c (dup2): Manage preprocessor macros correctly.
+   (rpl_dup2_fchdir): Rename from rpl_dup2, and let dup2 module take
+   care of mingw bugs.
+
dup2-tests: test previous patch
* modules/dup2-tests: New file.
* tests/test-dup2.c: Likewise.
diff --git a/doc/posix-functions/dup2.texi b/doc/posix-functions/dup2.texi
index bfaff38..c8f2ca1 100644
--- a/doc/posix-functions/dup2.texi
+++ b/doc/posix-functions/dup2.texi
@@ -13,6 +13,10 @@ This function always returns 0 for success on some platforms:
 mingw.

 @item
+This function can hang when duplicating an fd to itself on some platforms:
+mingw.
+
+...@item
 This function returns 0 for dup2 (1, 1) on some platforms:
 Cygwin 1.5.x.

diff --git a/lib/dup2.c b/lib/dup2.c
index e5d3de4..6d61829 100644
--- a/lib/dup2.c
+++ b/lib/dup2.c
@@ -26,19 +26,42 @@
 #include 
 #include 

+#if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
+/* Get declarations of the Win32 API functions.  */
+# define WIN32_LEAN_AND_MEAN
+# include 
+#endif
+
 #if REPLACE_DUP2
-/* On mingw, dup2 exists, but always returns 0 for success.  */
+
+# undef dup2
+
 int
-dup2 (int fd, int desired_fd)
-#undef dup2
+rpl_dup2 (int fd, int desired_fd)
 {
-  int result = dup2 (fd, desired_fd);
+  int result;
+# if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
+  /* If fd is closed, mingw hangs on dup2 (fd, fd).  If fd is open,
+ dup2 (fd, fd) returns 0, but all further attempts to use fd in
+ future dup2 calls will hang.  */
+  if (fd == desired_fd)
+{
+  if ((HANDLE) _get_osfhandle (fd) == INVALID_HANDLE_VALUE)
+{
+  errno = EBADF;
+  return -1;
+}
+  return fd;
+}
+# endif
+  result = dup2 (fd, desired_fd);
   if (result == 0)
 result = desired_fd;
   return result;
 }

 #else /* !REPLACE_DUP2 */
+
 /* On older platforms, dup2 did not exist.  */

 # ifndef F_DUPFD
diff --git a/lib/fchdir.c b/lib/fchdir.c
index cc2fa63..d51d963 100644
--- a/lib/fchdir.c
+++ b/lib/fchdir.c
@@ -172,18 +172,19 @@ rpl_dup (int oldfd)
   return newfd;
 }

+/* Our  replacement overrides dup2 twice; be sure to pick
+   the one we want.  */
+#if REPLACE_DUP2
+# undef dup2
+# define dup2 rpl_dup2
+#endif
+
 int
-rpl_dup2 (int oldfd, int newfd)
-#undef dup2
+rpl_dup2_fchdir (int oldfd, int newfd)
 {
   int retval = dup2 (oldfd, newfd);
-#if REPLACE_DUP2
-  /* Inline mingw replacement from dup2.c.  */
-  if (retval == 0)
-retval = newfd;
-#endif

-  if (retval >= 0 && oldfd >= 

[PATCH] vc-list-files: avoid failure when /bin/sh is dash

[Jim Meyering]

I've just pushed the following.
It fixes a nasty little portability problem:

>From 7c385af22c99df5eceda1e82d7aa595e6d5cb796 Mon Sep 17 00:00:00 2001
From: Jim Meyering 
Date: Tue, 21 Jul 2009 18:24:22 +0200
Subject: [PATCH] vc-list-files: avoid failure when /bin/sh is dash

* build-aux/vc-list-files: Avoid a shell portability problem with dash.
On some Debian based systems, /bin/sh is a symlink to dash, and running
this command would omit the "/" following each 'tests' prefix:
  dash -x build-aux/vc-list-files -C . tests
That is because bash and dash work differently:
  $ for i in bash dash; do $i -c 'a=odd; a=ok b=$a; echo '$i' $b'; done
  bash ok
  dash odd
---
 ChangeLog   |   12 
 build-aux/vc-list-files |4 ++--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 6a89b40..b471369 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2009-07-21  Jim Meyering  
+
+   vc-list-files: avoid failure when /bin/sh is dash
+   * build-aux/vc-list-files: Avoid a shell portability problem with dash.
+   On some Debian based systems, /bin/sh is a symlink to dash, and running
+   this command would omit the "/" following each 'tests' prefix:
+ dash -x build-aux/vc-list-files -C . tests
+   That is because bash and dash work differently:
+ $ for i in bash dash; do $i -c 'a=odd; a=ok b=$a; echo '$i' $b'; done
+ bash ok
+ dash odd
+
 2009-07-21  Eric Blake  

dup2-tests: test previous patch
diff --git a/build-aux/vc-list-files b/build-aux/vc-list-files
index 9376e3d..cc716e9 100755
--- a/build-aux/vc-list-files
+++ b/build-aux/vc-list-files
@@ -2,7 +2,7 @@
 # List version-controlled file names.

 # Print a version string.
-scriptversion=2009-04-25.13; # UTC
+scriptversion=2009-07-21.16; # UTC

 # Copyright (C) 2006-2009 Free Software Foundation, Inc.

@@ -74,7 +74,7 @@ test "x$dir" = x && dir=.
 if test -d .git; then
   test "x$dir" = x. \
 && dir= sed_esc= \
-|| dir="$dir/" sed_esc=`echo "$dir"|sed 's,\([\\/]\),\1,g'`
+|| { dir="$dir/"; sed_esc=`echo "$dir"|env sed 's,\([\\/]\),\1,g'`; }
   # Ignore git symlinks - either they point into the tree, in which case
   # we don't need to visit the target twice, or they point somewhere
   # else (often into a submodule), in which case the content does not
--
1.6.4.rc1.189.g9f628

Re: [PATCH] vc-list-files: avoid failure when /bin/sh is dash

[Eric Blake]

Jim Meyering  meyering.net> writes:

> That is because bash and dash work differently:
>   $ for i in bash dash; do $i -c 'a=odd; a=ok b=$a; echo '$i' $b'; done
>   bash ok
>   dash odd

Good catch.  And yes, this is already documented in the autoconf manual on 
shell portability; the order of assignments is unspecified (so you should treat 
dependent variables similarly to how you follow C rules for sequence points).

-- 
Eric Blake

Re: [PATCH] lib/sha1.h: wrap declarations in extern "C" scope when included from C++

[Peter Simons]

Hi Jim,

 > Would you please adjust that patch to do the same for all lib/sha*.h
 > files as well as lib/md5.h, and (if Simon agrees) lib/md[24].h?

sure, the updated patch is attached below. 

Take care,
Peter

>From 98e9105fa23067d396f25beb8406cfe407de469d Mon Sep 17 00:00:00 2001
From: Peter Simons 
Date: Tue, 21 Jul 2009 15:22:24 +0200
Subject: [PATCH 1/2] Wrap declarations in extern "C" scope when headers are 
included from C++.

---
 lib/md2.h|8 
 lib/md4.h|8 
 lib/md5.h|8 
 lib/sha1.h   |8 
 lib/sha256.h |8 
 lib/sha512.h |8 
 6 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/lib/md2.h b/lib/md2.h
index 401604e..3535e29 100644
--- a/lib/md2.h
+++ b/lib/md2.h
@@ -22,6 +22,10 @@
 # include 
 # include 
 
+# ifdef __cplusplus
+extern "C" {
+# endif
+
 # define MD2_DIGEST_SIZE 16
 
 /* Structure to save state of computation between the single steps.  */
@@ -73,4 +77,8 @@ extern int md2_stream (FILE *stream, void *resblock);
digest.  */
 extern void *md2_buffer (const char *buffer, size_t len, void *resblock);
 
+# ifdef __cplusplus
+}
+# endif
+
 #endif
diff --git a/lib/md4.h b/lib/md4.h
index 937794c..6b49da5 100644
--- a/lib/md4.h
+++ b/lib/md4.h
@@ -22,6 +22,10 @@
 # include 
 # include 
 
+# ifdef __cplusplus
+extern "C" {
+# endif
+
 # define MD4_DIGEST_SIZE 16
 
 /* Structure to save state of computation between the single steps.  */
@@ -79,4 +83,8 @@ extern int md4_stream (FILE * stream, void *resblock);
digest.  */
 extern void *md4_buffer (const char *buffer, size_t len, void *resblock);
 
+# ifdef __cplusplus
+}
+# endif
+
 #endif
diff --git a/lib/md5.h b/lib/md5.h
index 3ae657b..0769edb 100644
--- a/lib/md5.h
+++ b/lib/md5.h
@@ -54,6 +54,10 @@
 # define __md5_stream md5_stream
 #endif
 
+# ifdef __cplusplus
+extern "C" {
+# endif
+
 /* Structure to save state of computation between the single steps.  */
 struct md5_ctx
 {
@@ -115,4 +119,8 @@ extern int __md5_stream (FILE *stream, void *resblock) 
__THROW;
 extern void *__md5_buffer (const char *buffer, size_t len,
   void *resblock) __THROW;
 
+# ifdef __cplusplus
+}
+# endif
+
 #endif /* md5.h */
diff --git a/lib/sha1.h b/lib/sha1.h
index 4ffda7a..93babd2 100644
--- a/lib/sha1.h
+++ b/lib/sha1.h
@@ -23,6 +23,10 @@
 # include 
 # include 
 
+# ifdef __cplusplus
+extern "C" {
+# endif
+
 #define SHA1_DIGEST_SIZE 20
 
 /* Structure to save state of computation between the single steps.  */
@@ -81,4 +85,8 @@ extern int sha1_stream (FILE *stream, void *resblock);
digest.  */
 extern void *sha1_buffer (const char *buffer, size_t len, void *resblock);
 
+# ifdef __cplusplus
+}
+# endif
+
 #endif
diff --git a/lib/sha256.h b/lib/sha256.h
index a63b201..3dfcb26 100644
--- a/lib/sha256.h
+++ b/lib/sha256.h
@@ -21,6 +21,10 @@
 # include 
 # include 
 
+# ifdef __cplusplus
+extern "C" {
+# endif
+
 /* Structure to save state of computation between the single steps.  */
 struct sha256_ctx
 {
@@ -80,4 +84,8 @@ extern int sha224_stream (FILE *stream, void *resblock);
 extern void *sha256_buffer (const char *buffer, size_t len, void *resblock);
 extern void *sha224_buffer (const char *buffer, size_t len, void *resblock);
 
+# ifdef __cplusplus
+}
+# endif
+
 #endif
diff --git a/lib/sha512.h b/lib/sha512.h
index ed12d54..20bb09b 100644
--- a/lib/sha512.h
+++ b/lib/sha512.h
@@ -22,6 +22,10 @@
 
 # include "u64.h"
 
+# ifdef __cplusplus
+extern "C" {
+# endif
+
 /* Structure to save state of computation between the single steps.  */
 struct sha512_ctx
 {
@@ -84,4 +88,8 @@ extern int sha384_stream (FILE *stream, void *resblock);
 extern void *sha512_buffer (const char *buffer, size_t len, void *resblock);
 extern void *sha384_buffer (const char *buffer, size_t len, void *resblock);
 
+# ifdef __cplusplus
+}
+# endif
+
 #endif
-- 
1.6.3.3

>From e238bc65557e9698ec90393ce3d545aaf56db41f Mon Sep 17 00:00:00 2001
From: Peter Simons 
Date: Tue, 21 Jul 2009 15:23:55 +0200
Subject: [PATCH 2/2] tests/test-sha1.c: literal strings are immutable; don't 
assign them to 'char *'

---
 tests/test-sha1.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/test-sha1.c b/tests/test-sha1.c
index 0cfb309..4742138 100644
--- a/tests/test-sha1.c
+++ b/tests/test-sha1.c
@@ -25,8 +25,8 @@
 int
 main (int argc, char *argv[])
 {
-  char *in1 = "abcdefgh";
-  char *out1 = "\x42\x5a\xf1\x2a\x07\x43\x50\x2b"
+  const char *in1 = "abcdefgh";
+  const char *out1 = "\x42\x5a\xf1\x2a\x07\x43\x50\x2b"
 "\x32\x2e\x93\xa0\x15\xbc\xf8\x68\xe3\x24\xd5\x6a";
   char buf[SHA1_DIGEST_SIZE];
 
-- 
1.6.3.3

Re: new module pipe-filter

[Bruno Haible]

Hi Paolo,

Thanks for the comments!

> I don't like very much the design of this module.  The problem is that 
> it requires excessive effort on the child's part to buffer writes and/or 
> to prepare all of the filter's input upfront.

You mean, on the parent's part, I guess? (The module's goal is precisely
to do more work in the parent, so that clients which do reasonable
buffering don't cause deadlocks.)

> A nicer interface IMHO could be:
> 
> The caller will write to the subprocess through filter_write; during
> calls to filter_write, the done_read function may be called to
> process any data that the subprocess has written. ...
> The done_read function may be called in a different thread than
> the current thread, depending on the platform.

You are right that my proposed module is specialized for the case that
  - the control structure of the writer is simple, AND
  - the control structure of the reader is simple,
so that both can be dissected in repeated calls of the same function.

Your proposal is more general, but still assumes that
  - the control structure of the reader is simple.

A symmetrical proposal could be done for the case that
  - the control structure of the writer is simple.

And finally, in the case that both the reader and the writer part are
complex, the best bet is to do real multithreading on all platforms
(using the 'thread' module), while saying "not implemented" on exotic
platforms like Haiku or Interix.

Is there demand for these three other use-cases? I implemented only
the first one because that happened to be the one I needed in 'msgfilter'.
I am open to your requirements.

Bruno

Re: new module pipe-filter

[Paolo Bonzini]

> Your proposal is more general, but still assumes that
>   - the control structure of the reader is simple.

This is what Bison requires.  Actually Bison's reader is complex, buy
the output is fed to a Flex scanner, which takes care of the complexity.

> A symmetrical proposal could be done for the case that
>   - the control structure of the writer is simple.

I don't know of any usecase here.

Paolo

fchown-stub.c not pulled in for DJGPP 2.03p2

[Rugxulo]

Hey,
   I'm really not trying to be a pest, honest, but I personally still
use DJGPP (on Vista, XP, and real DOS [MS- / DR- / Free-], even).
DJGPP still hasn't ever finished the final 2.04, so it's stuck at
beta. Hence the DJGPP guys still port stuff to both 2.03p2 and 2.04.
DJGPP 2.04 beta does have fchown() but 2.03p2 "stable" (tested a lot
more) doesn't. Hence you already have fchown-stub.c. But it isn't
being pulled in for some reason (e.g. ZILE 2.3.9). It's not like I
can't hack the makefile to do so, but I'm just saying ... might be a
bug.

P.S. Two other things I already mentioned but may be of no use to use
(depending):

1). My suggested code snippet for detecting "selected display CON
codepage" in MS- / DR- / FreeDOS / Win9x (but not XP, Vista, etc),
e.g. for localcharset.c. I've been told that DOS isn't relevant
anymore, but FreeDOS is GPL and still updated (see June's kernel 2038
release) as is DJGPP (well, ports of GCC 4.4.0 and sed 4.2 [Gnulib!],
at least).

2). Vista by default (non-Admin) doesn't like MSVCRT.DLL's / MSVC 6's
tmpfile(), at least in all the paq8 series (Matt Mahoney, et al). This
is one reason I use DJGPP, no such problems (despite Windows bugs).
I'm told you have a tmpfile() replacement somewhere, but I've never
checked yet. (I already worked around the issue in source via some
really dumb hackish way myself.) In fact, the Win32 compile of
AdvanceComp (advzip, advdef) stopped working recently, which I blame
on Vista SP2 (gah, what the heck ...), yet another example of DJGPP
working around the problem (and yes, I know, DPMI limit bug ... but
SP1 + registry hack fixed that although Win2k3 is still broken, bad MS
!).

In short, DJGPP sometimes works where MinGW does not. (Yes, Cygwin
works but has license issues and is slower. But at least Cygwin and
DJGPP libs can be bugfixed if necessary.)