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

[Jim Meyering]

Peter Simons wrote:
> 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.

Thanks.
I've pushed them, after adding a ChangeLog entry to each.

>From abc4e3f768914ecc82270adfccef5f3fea98 Mon Sep 17 00:00:00 2001
From: Peter Simons 
Date: Tue, 21 Jul 2009 15:23:55 +0200
Subject: [PATCH 1/2] tests-sha1: don't assign literal string to 'char *' 
variable

* tests/test-sha1.c (main): Declare locals with "const" to match
attributes of the right hand side.
---
 ChangeLog |6 ++
 tests/test-sha1.c |4 ++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 2bb96cf..718af87 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2009-07-22  Peter Simons  
+
+   tests-sha1: don't assign literal string to 'char *' variable
+   * tests/test-sha1.c (main): Declare locals with "const" to match
+   attributes of the right hand side.
+
 2009-07-21  Eric Blake  

dup2: fix more mingw problems
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.4.rc1.189.g9f628


>From e89d33fe93612a3e0024c5d2d3751c3f722de939 Mon Sep 17 00:00:00 2001
From: Peter Simons 
Date: Tue, 21 Jul 2009 15:22:24 +0200
Subject: [PATCH 2/2] C++: wrap md2,md5,sha1,etc. function declarations in 
extern "C" scope

* lib/md2.h [__cplusplus]: Wrap declarations in extern "C" scope.
* lib/md4.h: Likewise.
* lib/md5.h: Likewise.
* lib/sha1.h: Likewise.
* lib/sha256.h: Likewise.
* lib/sha512.h: Likewise.
---
 ChangeLog|8 
 lib/md2.h|8 
 lib/md4.h|8 
 lib/md5.h|8 
 lib/sha1.h   |8 
 lib/sha256.h |8 
 lib/sha512.h |8 
 7 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 718af87..cca4ce9 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
 2009-07-22  Peter Simons  

+   C++: wrap md2,md5,sha1,etc. function declarations in extern "C" scope
+   * lib/md2.h [__cplusplus]: Wrap declarations in extern "C" scope.
+   * lib/md4.h: Likewise.
+   * lib/md5.h: Likewise.
+   * lib/sha1.h: Likewise.
+   * lib/sha256.h: Likewise.
+   * lib/sha512.h: Likewise.
+
tests-sha1: don't assign literal string to 'char *' variable
* tests/test-sha1.c (main): Declare locals with "const" to match
attributes of the right hand side.
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
in

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

[Simon Josefsson]

Jim Meyering  writes:

> Peter Simons wrote:
>> 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.
>
> Thanks.
> I've pushed them, after adding a ChangeLog entry to each.

Thanks!

/Simon

Re: building directly from $(top_builddir)

[Akim Demaille]

Le 18 juil. 09 à 18:06, Bruno Haible a écrit :

Hi Bruno!

Thank you for the attention you paid to my message!


Eric Blake wrote:
gnulib-tool could make this part easier by automating it somehow (a  
new
command line option to state whether the gnulib.mk fragment will be  
used
in the current directory [default], or included from some other  
directory

where all relative paths need an extra prefix [as in bison's case]).


Such a feature would require changes (to insert $prefix here and  
there) in
many places, i.e. in many module descriptions. That's hardly  
maintainable
(and rarely tested, since most gnulib users would not use this  
feature).


The alternative quite easy: Just include a tiny Makefile.am in the
subdirectory, that does

  include gnulib.mk

and invoke that Makefile from the top-level directory, by use of
AC_CONFIG_SUBDIRS.


Of course, but that's exactly what I departed from.  I actually
wrote a small post-processing tool that converts gnulib.mk into
one with the needed lib/ added here and there.


Does bison have any specific problems following this approach that
everyone else has used so far?


First of all, I'm not asking anything to the gnulib community, I
have the conversion tool, it does a reasonable job, and I can
live with it.  Of course if the feature is provided by gnulib
itself, that's better :)

The motivations are speed and accuracy.

After having used for years one Makefile.am per directory, I
started converting my projects to use fewer Makefile.am,
sometimes just a single one, using extensively "include
foo/local.mk" and so forth.

Since today there is no assistance from Automake, it is quite
unpleasant, as you need to add prefix a bit everywhere.  If some
patches of Ralf make it into a forthcoming release, then this
should be made easier and more consistent thanks to
meta-variables that expand to the current include-prefix.

But once this done, concurrent builds are much more efficient.
Not only because you expose more concurrency opportunity to Make,
but also because your dependencies are more accurate: instead of
relying on the ordering of SUBDIRS to go into lib/ before
compiling in src/, Make can see whether the library needs to be
updated or not.  And it turns out that, at least in some packages
I work on, it is not always needed.

The effect is even more striking when the test suite is itself
relying on the dependencies: running make check TESTS='...'  will
just compile what is needed, instead of recuring in a bazillon of
useless directories to see it has nothing to do.  Since my test
suites actually maintain some state, tests that were not updated
will not even be run.  This can be provide very large savings.

Finally, about accuracy.  I have been bitten sometimes because of
incomplete "bouncing" targets.  For instance Bison uses various
auxiliary tools to generate bits of its documentation (that lives
in doc/) from bison --help.  If you want to be able to trust
"make -C doc pdf" (even if "make" was not run beforehand), you
need a small fake target that runs "make -C ../src" when needed.
But then, what are the dependencies?  I used approximations,
which eventually bite you.  Now I don't need all this, I just
use "the real thing".


I'm not trying to convince here, just explaining why I prefer
this today.  Since I work on packages that embed others (and
quite deeply actually), everything that can be used to speed
things up is nice.

Of course there are several problems.  The one that annoys me the
most is the total lack of scoping in Makefiles, which becomes a
real problem when you want to play with various sets of *FLAGS.
So I use foo_CPPFLAGS, which, unfortunately causes Automake to
create adhoc rules for every single file, which results in
possibly extremely large Makefiles which Make takes quite long to
load...

I wish Automake had a "I *will* use GNU Make on the other side"
option.  Something that would help keeping the Makefiles smaller.

Cheers!

Re: new module pipe-filter

[Paolo Bonzini]

On 07/22/2009 12:27 AM, Paolo Bonzini wrote:

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, but
the output is fed to a Flex scanner, which takes care of the complexity.


Here is some code with an example, the Win32 part I'll do in the next 
few days.  If I had to choose one of the three cases you mentioned, I'd 
include this one in gnulib.  It shouldn't be too bad to adapt msgfilter 
to this API; for Bison it is overkill.


Paolo
/* Filtering of data through a subprocess.
   Copyright (C) 2009 Free Software Foundation, Inc.
   Written by Bruno Haible , 2009.

   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 3 of the License, 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, see .  */

#ifndef _PIPE_FILTER_H
#define _PIPE_FILTER_H

#include 
#include 


#ifdef __cplusplus
extern "C" {
#endif


/* Piping data through a subprocess in the naïve way - write data to the
   subprocess and read from the subprocess when you expect it to have
   produced results - is subject to two kinds of deadlocks:
   1) If you write more than PIPE_MAX bytes or, more generally, if you write
  more bytes than the subprocess can handle at once, the subprocess
  may write its data and wait on you to read it, but you are currently
  busy writing.
   2) When you don't know ahead of time how many bytes the subprocess
  will produce, the usual technique of calling read (fd, buf, BUFSIZ)
  with a fixed BUFSIZ will, on Linux 2.2.17 and on BSD systems, cause
  the read() call to block until *all* of the buffer has been filled.
  But the subprocess cannot produce more data until you gave it more
  input.  But you are currently busy reading from it.
   This module provides a function that pipes data to a subprocess and
   gets its output back via a callback, without risking these deadlocks.  */


typedef void (*done_read_fn) (char *read_buf, size_t num_bytes_read,
			  void *private_data);

struct filter;

/* 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,
  const char **prog_argv,
  bool null_stderr, bool exit_on_error,
  char *read_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 or
   the subprocess has exited.

   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 

Re: building directly from $(top_builddir)

[Ralf Wildenhues]

Hello Akim,

* Akim Demaille wrote on Wed, Jul 22, 2009 at 05:52:16PM CEST:
> 
> Of course there are several problems.  The one that annoys me the
> most is the total lack of scoping in Makefiles, which becomes a
> real problem when you want to play with various sets of *FLAGS.
> So I use foo_CPPFLAGS, which, unfortunately causes Automake to
> create adhoc rules for every single file, which results in
> possibly extremely large Makefiles which Make takes quite long to
> load...
> 
> I wish Automake had a "I *will* use GNU Make on the other side"
> option.  Something that would help keeping the Makefiles smaller.

As in:

  # Caution!  The following
  # - subverts automake's renaming of targets with per-target features,
  # - relies on the specific names of object files (an undocumented
  #   internal automake detail), namely absense of per-target flags
  #   and existence of inference rules for these objects,
  # - requires GNU make.
  # Do not use this technique for anything automake should detect.
  # Do expect this to break with Automake 1.X+1.

  AUTOMAKE_OPTIONS = -Wno-portability
  foo.$(OBJEXT): AM_CPPFLAGS = -Dobject_specific=1
  bar.$(OBJEXT): AM_CFLAGS += -O0
  $(baz_OBJECTS): AM_CXXFLAGS += ...

?

Because if you use per-target flags, then there is not much Automake can
do if it is to keep up the renaming scheme: it has to output per-object
rules.  And these only factor so far.

Cheers,
Ralf

PS: Bug reports against Automake from newbies using the above will be
forwarded to you.  :-)

PPS: For extremely large makefiles, somebody should write an efficient
sparse+wildcard matrix transpose (sparse dag reversal if you like one
made-up term better than the other) and a portable parallel inotifyd to
feed makefiles into a parallel Beta build system with suitable feature
set to match/map that part of GNU make functionality that doesn't depend
on dag traversal order (and maybe also the other part); see this thread:
.

lib/fseeko.c fails to compile on QNX 6.4.1

[mkraai]

Howdy,

lib/fseeko.c fails to compile on QNX 6.4.1 because _MWRITE isn't defined. 
The attached patch manually expands it, as is done in the other files that 
use this symbol (e.g., lib/fpurge.c).

Matt


The server  made the following annotations   

-

This message contains information that may be privileged or confidential and is 
the property of Beckman Coulter, Inc.  It is intended only for the person to 
whom it is addressed.  If you are not the intended recipient, you are not 
authorized to read, print, retain, copy, disseminate, distribute or use this 
message or any part thereof.  If you receive this message in error, please 
notify the sender immediately and delete all copies of this message.

-



0001-Fix-port-to-QNX.patch
Description: Binary data

Re: undefined behavior in closeout, aggravated by libsigsegv

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Bruno Haible on 7/18/2009 1:03 AM:
>> there is currently a 
>> thread on the cygwin list about a crash under Windows 2008 R2 64-bit, where 
>> Windows has tightened the rules on what forms a valid SEH exception chain 
>> and 
>> the cygwin handler was violating those rules; and that thread has also 
>> raised 
>> the concern that libsigsegv may be making the same mistakes by trying to 
>> override cygwin's handler:
> 
> The mail at http://cygwin.com/ml/cygwin/2009-07/msg00607.html indicates that
> the problem was with incorrect nesting of SEH exception chain 
> additions/removals.
> The values of the addresses in that chain appear to be irrelevant. Thus it
> does not matter whether libsigsegv is compiled as a DLL or statically. At 
> least
> that's what I understand from the thread.

Actually, the bug is that libsigsegv is too eager to claim that an SEH
exception is a SEGV, even if cygwin was otherwise prepared to handle it
and not raise SIGSEGV.  The fix is to delay handling of the fault until
after the SIGSEGV has actually been raised, although for cygwin 1.5, the
SEH handler is still needed to learn the faulting address since it wasn't
until today's patch to cygwin 1.7 that si_addr was populated correctly.

Here's three patches that add test cases, then respectively fixes cygwin
1.7 and 1.5 to pass the new tests.  I've also tested that on platforms
like Linux that the new tests pass, as well as testing that mingw skips
the tests but otherwise still compiles fine.

$ git pull git://repo.or.cz/libsigsegv/ericb.git master

- --
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

iEYEARECAAYFAkpn4moACgkQ84KuGfSFAYCfJQCfYbPJk2csPQu18zqEyCItb4YV
Sa8AoNStSmbs995mK51Vp1wMivy1x8sy
=H36q
-END PGP SIGNATURE-
>From 8a62e3538cad933a1421578499d6ce170dd035a6 Mon Sep 17 00:00:00 2001
From: Eric Blake 
Date: Wed, 22 Jul 2009 13:36:17 -0600
Subject: [PATCH 1/3] Detect library bug when used on cygwin.

* m4/efault.m4 (SV_EFAULT): New file.
* tests/efault1.c: Likewise.
* tests/efault2.c: Likewise.
* tests/efault3.c: Likewise.
* tests/Makefile.am (TESTS, noinst_PROGRAMS): Build new tests.
* configure.ac (SV_EFAULT): Invoke new macro.

Signed-off-by: Eric Blake 
---
 ChangeLog |   10 ++
 configure.ac  |3 ++
 m4/efault.m4  |   27 +++
 tests/Makefile.am |2 +
 tests/efault1.c   |   72 +
 tests/efault2.c   |   81 ++
 tests/efault3.c   |   92 +
 7 files changed, 287 insertions(+), 0 deletions(-)
 create mode 100644 m4/efault.m4
 create mode 100644 tests/efault1.c
 create mode 100644 tests/efault2.c
 create mode 100644 tests/efault3.c

diff --git a/ChangeLog b/ChangeLog
index c2fa127..d0a69e0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2009-07-22  Eric Blake  
+
+   Detect library bug when used on cygwin.
+   * m4/efault.m4 (SV_EFAULT): New file.
+   * tests/efault1.c: Likewise.
+   * tests/efault2.c: Likewise.
+   * tests/efault3.c: Likewise.
+   * tests/Makefile.am (TESTS, noinst_PROGRAMS): Build new tests.
+   * configure.ac (SV_EFAULT): Invoke new macro.
+
 2009-06-23  Bruno Haible  

* Makefile.am (check-next): No longer ask for copies of config.log.
diff --git a/configure.ac b/configure.ac
index 2a54c96..1393642 100644
--- a/configure.ac
+++ b/configure.ac
@@ -896,6 +896,9 @@ AC_DEFINE_UNQUOTED([CFG_HANDLER], ["$CFG_HANDLER"],
   [The name of the file implementing the handler functionality.])
 AC_SUBST([CFG_HANDLER])

+dnl Learn whether we can test for EFAULT handling.
+SV_EFAULT
+
 { echo; echo "${term_bold}Build Parameters:${term_norm}"; } >& AS_MESSAGE_FD

 dnl Relocatability is a nop for this package.
diff --git a/m4/efault.m4 b/m4/efault.m4
new file mode 100644
index 000..d846a48
--- /dev/null
+++ b/m4/efault.m4
@@ -0,0 +1,27 @@
+# efault.m4 serial 1 (libsigsegv-2.7)
+dnl Copyright (C) 2009 Eric Blake 
+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
+dnl that contains a configuration script generated by Autoconf, under
+dnl the same distribution terms as the rest of that program.
+
+dnl Determine whether the OS catches some mistakes with EFAULT, to ensure
+dnl that libsigsegv does not interfere with EFAULT handling.
+AC_DEFUN([SV_EFAULT], [
+  AC_CACHE_CHECK([whether EFAULT is supported], [sv_cv_efault_supported], [
+AC_RUN_IFELSE([
+  AC_LANG_PROGRAM([[
+#include 
+#include 
+#include 
+]], [return !(open (NULL, O_RDONLY) == -1 && errn

Re: lib/fseeko.c fails to compile on QNX 6.4.1

[Bruno Haible]

Hi,

Matt Kraai wrote:
> lib/fseeko.c fails to compile on QNX 6.4.1 because _MWRITE isn't defined. 
> The attached patch manually expands it, as is done in the other files that 
> use this symbol (e.g., lib/fpurge.c).

Thanks. I committed your patch.

Btw, the QNX support was untested when it was committed on 2007-10-03. Does
"make check" pass all the tests for you?

Bruno