absolute-header.m4 fix for Sun C 5.8

[Paul Eggert]

With the stdint module, Sun C 5.8 issued warnings like this:

"./stdint.h", line 46: warning: #include of /usr/include/... may be non-portable

I installed the following to suppress these bogus warnings:

2006-07-04  Paul Eggert  <[EMAIL PROTECTED]>

* absolute-header.m4 (gl_ABSOLUTE_HEADER): Prepend three slashes
to the absolute name, not just one, to bypass Sun C 5.8's
"warning: #include of /usr/include/... may be non-portable".

--- m4/absolute-header.m4   4 Jul 2006 06:37:10 -   1.1
+++ m4/absolute-header.m4   4 Jul 2006 07:37:12 -
@@ -1,4 +1,4 @@
-# absolute-header.m4 serial 3
+# absolute-header.m4 serial 4
 dnl Copyright (C) 2006 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -13,6 +13,8 @@ dnl From Derek Price.
 # ABSOLUTE_SYS_INTTYPES_H to the `<>' quoted absolute name of sys/inttypes.h
 # in config.h
 # (e.g. `#define ABSOLUTE_SYS_INTTYPES_H ').
+# The three "///" are to pacify Sun C 5.8, which otherwise would say
+# "warning: #include of /usr/include/... may be non-portable".
 AC_DEFUN([gl_ABSOLUTE_HEADER],
 [AC_LANG_PREPROC_REQUIRE()dnl
 AC_FOREACH([gl_HEADER_NAME], [$1],
@@ -29,13 +31,13 @@ dnl eval is necessary to expand ac_cpp.
 dnl Ultrix and Pyramid sh refuse to redirect output of eval, so use subshell.
   AS_VAR_SET(gl_absolute_header,
 [`(eval "$ac_cpp conftest.$ac_ext") 2>&AS_MESSAGE_LOG_FD |
-sed -n 
'\#/]m4_quote(m4_defn([gl_HEADER_NAME]))[#{s#.*"\(.*/]m4_quote(m4_defn([gl_HEADER_NAME]))[\)".*#\1#;p;q;}'`])
+sed -n 
'\#/]m4_quote(m4_defn([gl_HEADER_NAME]))[#{s#.*"\(.*/]m4_quote(m4_defn([gl_HEADER_NAME]))[\)".*#\1#;s#^/[^/]#//&#;p;q;}'`])
 fi
 AS_VAR_POPDEF([ac_header_exists])dnl
 ])dnl
   AC_DEFINE_UNQUOTED(AS_TR_CPP([ABSOLUTE_]m4_quote(m4_defn([gl_HEADER_NAME]))),
  [],
- [Define this to the absolute name of 
<]m4_quote(m4_defn([gl_HEADER_NAME]))[>.])
+ [Define this to an absolute name of 
<]m4_quote(m4_defn([gl_HEADER_NAME]))[>.])
   AS_VAR_POPDEF([gl_absolute_header])dnl
 ])dnl
 ])# gl_ABSOLUTE_HEADER

Re: cycle-check.h fix imported from coreutils

[Paul Eggert]

"Mark D. Baushke" <[EMAIL PROTECTED]> writes:

> -lib_SOURCES += cycle-check.c cycle-check.h dev-ino.h
> +lib_SOURCES += cycle-check.c cycle-check.h dev-ino.h same-inode.h

Thanks for catching that; I installed it.

Re: [bug-gnulib] strndup module and crosscompiling

[Bruno Haible]

Martin Lambers wrote:
> gnulib/m4/strndup.m4 checks for a deficient strndup() function. When
> crosscompiling, it assumes that strndup() is broken if the target is AIX
> and that it is ok otherwise. 
> 
> This fails when crosscompiling to a target that has no strndup()
> function at all, such as MinGW: HAVE_STRNDUP will wrongly be defined to
> 1.

Thanks for reporting this. Does this patch work?

Bruno


2006-07-03  Bruno Haible  <[EMAIL PROTECTED]>

* strndup.m4 (gl_FUNC_STRNDUP): When cross-compiling, check whether
the function exists, before testing against AIX.
Reported by Martin Lambers <[EMAIL PROTECTED]>.

*** gnulib-20060703/m4/strndup.m4   2006-05-30 22:24:54.0 +0200
--- gnulib-20060703-modified/m4/strndup.m4  2006-07-04 01:48:07.0 
+0200
***
*** 1,4 
! # strndup.m4 serial 6
  dnl Copyright (C) 2002-2003, 2005-2006 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
--- 1,4 
! # strndup.m4 serial 7
  dnl Copyright (C) 2002-2003, 2005-2006 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
***
*** 27,39 
return s[13] != '\0';]])],
 [gl_cv_func_strndup=yes],
 [gl_cv_func_strndup=no],
![AC_EGREP_CPP([too risky], [
  #ifdef _AIX
! too risky
  #endif
!   ],
!   [gl_cv_func_strndup=no],
!   [gl_cv_func_strndup=yes])])])
if test $gl_cv_func_strndup = yes; then
  AC_DEFINE([HAVE_STRNDUP], 1,
[Define if you have the strndup() function and it works.])
--- 27,41 
return s[13] != '\0';]])],
 [gl_cv_func_strndup=yes],
 [gl_cv_func_strndup=no],
![AC_CHECK_FUNC([strndup],
!   [AC_EGREP_CPP([too risky], [
  #ifdef _AIX
!too risky
  #endif
!  ],
!  [gl_cv_func_strndup=no],
!  [gl_cv_func_strndup=yes])],
!   [gl_cv_func_strndup=no])])])
if test $gl_cv_func_strndup = yes; then
  AC_DEFINE([HAVE_STRNDUP], 1,
[Define if you have the strndup() function and it works.])

Re: [bug-gnulib] AC_HEADER_STDC

[Bruno Haible]

Derek R. Price wrote:
>   * m4/onceonly.m4,
>   m4/onceonly_2_57.m4
>   Don't call obsolescent AC_HEADER_STDC.

It's not called there, it's only used as an example. I've changed it
like this.

*** onceonly_2_57.m410 Aug 2005 12:06:39 -  1.6
--- onceonly_2_57.m44 Jul 2006 16:38:47 -
***
*** 1,5 
! # onceonly_2_57.m4 serial 3
! dnl Copyright (C) 2002-2003, 2005 Free Software Foundation, Inc.
  dnl This file is free software, distributed under the terms of the GNU
  dnl General Public License.  As a special exception to the GNU General
  dnl Public License, this file may be distributed as part of a program
--- 1,5 
! # onceonly_2_57.m4 serial 4
! dnl Copyright (C) 2002-2003, 2005-2006 Free Software Foundation, Inc.
  dnl This file is free software, distributed under the terms of the GNU
  dnl General Public License.  As a special exception to the GNU General
  dnl Public License, this file may be distributed as part of a program
***
*** 7,16 
  dnl the same distribution terms as the rest of that program.
  
  dnl This file defines some "once only" variants of standard autoconf macros.
! dnl   AC_CHECK_HEADERS_ONCE like  AC_CHECK_HEADERS
! dnl   AC_CHECK_FUNCS_ONCE   like  AC_CHECK_FUNCS
! dnl   AC_CHECK_DECLS_ONCE   like  AC_CHECK_DECLS
! dnl   AC_REQUIRE([AC_HEADER_STDC])  like  AC_HEADER_STDC
  dnl The advantage is that the check for each of the headers/functions/decls
  dnl will be put only once into the 'configure' file. It keeps the size of
  dnl the 'configure' file down, and avoids redundant output when 'configure'
--- 7,16 
  dnl the same distribution terms as the rest of that program.
  
  dnl This file defines some "once only" variants of standard autoconf macros.
! dnl   AC_CHECK_HEADERS_ONCE  like  AC_CHECK_HEADERS
! dnl   AC_CHECK_FUNCS_ONCElike  AC_CHECK_FUNCS
! dnl   AC_CHECK_DECLS_ONCElike  AC_CHECK_DECLS
! dnl   AC_REQUIRE([AC_FUNC_STRCOLL])  like  AC_FUNC_STRCOLL
  dnl The advantage is that the check for each of the headers/functions/decls
  dnl will be put only once into the 'configure' file. It keeps the size of
  dnl the 'configure' file down, and avoids redundant output when 'configure'
diff -c -3 -r1.7 onceonly.m4
*** onceonly.m4 19 Apr 2006 11:36:18 -  1.7
--- onceonly.m4 4 Jul 2006 16:38:47 -
***
*** 1,14 
! # onceonly.m4 serial 4 (gettext-0.15)
  dnl Copyright (C) 2002-2003, 2006 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
  dnl with or without modifications, as long as this notice is preserved.
  
  dnl This file defines some "once only" variants of standard autoconf macros.
! dnl   AC_CHECK_HEADERS_ONCE like  AC_CHECK_HEADERS
! dnl   AC_CHECK_FUNCS_ONCE   like  AC_CHECK_FUNCS
! dnl   AC_CHECK_DECLS_ONCE   like  AC_CHECK_DECLS
! dnl   AC_REQUIRE([AC_HEADER_STDC])  like  AC_HEADER_STDC
  dnl The advantage is that the check for each of the headers/functions/decls
  dnl will be put only once into the 'configure' file. It keeps the size of
  dnl the 'configure' file down, and avoids redundant output when 'configure'
--- 1,14 
! # onceonly.m4 serial 5 (gettext-0.15)
  dnl Copyright (C) 2002-2003, 2006 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
  dnl with or without modifications, as long as this notice is preserved.
  
  dnl This file defines some "once only" variants of standard autoconf macros.
! dnl   AC_CHECK_HEADERS_ONCE  like  AC_CHECK_HEADERS
! dnl   AC_CHECK_FUNCS_ONCElike  AC_CHECK_FUNCS
! dnl   AC_CHECK_DECLS_ONCElike  AC_CHECK_DECLS
! dnl   AC_REQUIRE([AC_FUNC_STRCOLL])  like  AC_FUNC_STRCOLL
  dnl The advantage is that the check for each of the headers/functions/decls
  dnl will be put only once into the 'configure' file. It keeps the size of
  dnl the 'configure' file down, and avoids redundant output when 'configure'

version-etc output format

[Gary V. Vaughan]

Has the format of version-etc output changed?

From GNU M4 1.4.x (doesn't use version-etc):

  $ m4 --version
  GNU M4 1.4.4
  Written by Rene' Seindal.

  Copyright (C) 2005 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Which matches the output of automake --version, autoconf --version, ls --version
and several others I tried.  However, compiled CVS M4 with latest gnulib, I get:

  $ ./src/m4 --version
  GNU M4 1.9a
  Copyright (C) 2006 Free Software Foundation, Inc.
  This is free software.  You may redistribute copies of it under the terms of
  the GNU General Public License .
  There is NO WARRANTY, to the extent permitted by law.

  Written by Rene' Seindal and Gary V. Vaughan.

This looks uglier IMHO.  Can we change swap the author and copyright blocks
in version-etc.c to match coreutils and others output?

Cheers,
Gary.
-- 
Gary V. Vaughan  ())_.  [EMAIL PROTECTED],gnu.org}
Research Scientist   ( '/   http://blog.azazil.net
GNU Hacker   / )=   http://trac.azazil.net/projects/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook



signature.asc
Description: OpenPGP digital signature

Re: [bug-gnulib] AC_HEADER_STDC

[Bruno Haible]

Derek R. Price wrote:
>   lib/mbswidth.c: Remove sections
>   dependent on !STDC_HEADERS.

Thanks, I committed to gnulib the same patch that I had done in gettext
a day earlier. It is identical to yours.

Bruno


2006-06-27  Bruno Haible  <[EMAIL PROTECTED]>

Assume ANSI C header files and  functions.
* mbswidth.c (IN_CTYPE_DOMAIN, ISPRINT, ISCNTRL): Remove macros.
(mbsnwidth): Use isprint, iscntrl instead.

*** mbswidth.c  28 Jun 2006 17:03:53 -  1.16
--- mbswidth.c  4 Jul 2006 16:45:23 -
***
*** 60,77 
  # endif
  #endif
  
- /* Get ISPRINT.  */
- #if defined (STDC_HEADERS) || (!defined (isascii) && !defined (HAVE_ISASCII))
- # define IN_CTYPE_DOMAIN(c) 1
- #else
- # define IN_CTYPE_DOMAIN(c) isascii(c)
- #endif
- /* Undefine to protect against the definition in wctype.h of Solaris 2.6.   */
- #undef ISPRINT
- #define ISPRINT(c) (IN_CTYPE_DOMAIN (c) && isprint (c))
- #undef ISCNTRL
- #define ISCNTRL(c) (IN_CTYPE_DOMAIN (c) && iscntrl (c))
- 
  /* Returns the number of columns needed to represent the multibyte
 character string pointed to by STRING.  If a non-printable character
 occurs, and MBSW_REJECT_UNPRINTABLE is specified, -1 is returned.
--- 60,65 
***
*** 195,204 
  {
unsigned char c = (unsigned char) *p++;
  
!   if (ISPRINT (c))
width++;
else if (!(flags & MBSW_REJECT_UNPRINTABLE))
!   width += (ISCNTRL (c) ? 0 : 1);
else
return -1;
  }
--- 183,192 
  {
unsigned char c = (unsigned char) *p++;
  
!   if (isprint (c))
width++;
else if (!(flags & MBSW_REJECT_UNPRINTABLE))
!   width += (iscntrl (c) ? 0 : 1);
else
return -1;
  }

Re: [bug-gnulib] Last few obsolescent macros

[Bruno Haible]

Derek R. Price wrote:
> Removing references to AC_HEADER_DIRENT (replacing with
> AC_CHECK_HEADERS_ONCE([dirent.h]))

Yes. All Unix systems nowadays have , OpenVMS too. But native Woe32
(MSVCRT, not mingw) doesn't.

Bruno

Re: new module for temporary files in temporary directories

[Bruno Haible]

Paul Eggert wrote:
> > The module is, so far, not optimized for asymptotic performance.
> > How many temporary files does 'sort' use? Is more than 1 temp files
> > realistic (each of size > 10 MB, giving a total of 100 GB) ?
> 
> Yes, I'm afraid it is.  People are sorting larger files these days,
> and GNU sort doesn't always pick good sizes for temporaries.

OK, I'll rewrite the datastructures to have average O(1) insertion and
removal cost.

> The function names use the verbs "enqueue" and "dequeue", not the noun
> "queue".  So we don't need a noun; we need two verbs.  How about
> "register" and "unregister"?

Yes, thanks. I'll use these function names.

> After looking at the code a bit more, I have another comment -- more a
> question, really.  Are all those "volatile"s really needed?
> 
> The C and POSIX standards are basically useless when it comes to
> "volatile", so I was wondering what informal rules of thumb you were
> using when programming, when deciding when to use "volatile" and when
> not to.

The rule of thumb is: If a data field can be written by the main program
and read by the signal handler, or vice versa, it needs to be marked as
'volatile'. Data fields which are read-only from the moment they are entered
into the data structure (such as the contents of strings) are not marked
'volatile'; I hope 'volatile' is not needed here.

1) The practical reason is that while developing libsigsegv, I noticed that
C does not have the notion of a "barrier": In code like this:

  set_up_datastructures();
  /* HERE I would like a barrier */
  signal(sig,my_signal_handler);

I would like a barrier to ensure that all memory stores of
set_up_datastructures()  have been performed before the signal handler
is activated. __asm__("" : : : "memory"); is not portable (works only with
GCC). Calls to an empty global function are optimized away by GCC 4. For
a concrete example, look at libsigsegv/sigsegv2.c:

  static volatile unsigned int logcount = 0;

  static void
  barrier ()
  {
  }

  ...
/* This access should call the handler.  */
((volatile int *)area2)[230] = 22;
/* This access should call the handler.  */
((volatile int *)area3)[412] = 33;
/* This access should not give a signal.  */
((volatile int *)area2)[135] = 22;
/* This access should call the handler.  */
((volatile int *)area1)[612] = 11;

barrier();

/* Check that the handler was called three times.  */
if (logcount != 3)
  exit (1);

If I omit the 'volatile' markers, gcc's scheduler will on some platforms
move the access to the 'logcount' variable to before the four memory
accesses. But at that moment its value is still 0 (since it's incremented
by the signal handler).

2) Another example is when a new list element is added to a list that
is accessed from the signal handler. If the compiler would reorder the
memory stores such that the list element is added to the list before it
is fully initialized, the signal handler would likely crash.

Similarly here:

  tmpdir->file[tmpdir->file_count] = xstrdup (absolute_file_name);
  tmpdir->file_count++;

3) The theoretical reason is that in ISO C, section 5.1.2.3.(5)
guarantees to me that memory stores have been performed at sequence points
only if I mark them 'volatile'. (I don't understand what 5.1.2.3.(4) is
talking about since GCC 4 takes the freedom to reorder memory loads and
stores arbitrarily across sequence points, if it can prove that there is
no aliasing.)

> I still don't understand "volatile", to be honest.

To me, "volatile" means: "Perform the memory access here and now, without
merging several memory accesses, without changing the memory word size
width, and without reordering." On multiprocessor systems with CPUs which
don't have automatic memory bus synchronization (bus watching logic), it
probably means that the compiler needs to emit instructions for explicit
synchronization among the CPUs.

ISO C++ says: "volatile  is  a hint to the implementation to avoid aggressive
  optimization involving the object because  the  value  of  the  object
  might  be  changed  by  means  undetectable by an implementation.  See
  _intro.execution_ for detailed semantics.  In general,  the  semantics
  of volatile are intended to be the same in C++ as they are in C."

Bruno

Re: [bug-gnulib] new module for temporary files in temporary directories

[Bruno Haible]

Ben Pfaff wrote:
> > /* Create a temporary directory.
> >PREFIX is used as a prefix for the name of the temporary directory. It
> >should be short and still give an indication about the program.
> >Return a fresh 'struct temp_dir' on success.  Upon error, an error 
> > message
> >is shown and NULL is returned.  */
> > extern struct temp_dir * create_temp_dir (const char *prefix);
> 
> I find the description just a little confusing: PREFIX is a
> prefix for the *base name* of the temporary directory.  It
> actually goes in the middle of the directory name.

I guess you are confused because of the distinction between "filename" in
the POSIX sense (= pathname component) and "filename" in the sense that
is matches a user's mind and that Paul Eggert wants to use also in APIs.

In the next version, this function will take an additional PARENTDIR argument,
to accomodate GNU sort's -T option. That should avoid the confusion in this
particular case.

Bruno

Re: OS/2 and stdarg module

[Bruno Haible]

Eric Blake wrote:
> Meanwhile, is it worth patching autoconf/lib/autoheader.m4 to complain when
> $2 of AH_VERBATIM is empty, so this mistake is less likely to occur in the
> future?

This would be welcome. Something like this (untested)?

*** autoheader.m4.bak   2005-05-14 09:00:39.0 +0200
--- autoheader.m4   2006-07-04 02:08:30.0 +0200
***
*** 67,74 
  #
  # Quote for Perl '' strings, which are those used by Autoheader.
  m4_define([AH_VERBATIM],
! [AS_LITERAL_IF([$1],
!  [AH_OUTPUT([$1], AS_ESCAPE([[$2]], [\\'']))])
  ])
  
  
--- 67,76 
  #
  # Quote for Perl '' strings, which are those used by Autoheader.
  m4_define([AH_VERBATIM],
! [m4_ifval([$1],
![AS_LITERAL_IF([$1],
! [AH_OUTPUT([$1], AS_ESCAPE([[$2]], [\\'']))])],
![AS_WARN([AH_VERBATIM invoked with only one argument])])
  ])
  
  

Re: simplification rewrite of stdint module installed into gnulib

[Bruno Haible]

Paul Eggert wrote:
>   * m4/longlong.m4 (AC_TYPE_LONG_LONG_INT): Backport from Autoconf 2.60,
>   but fix a bug, by requiring at least 64 bits.
>   * m4/ulonglong.m4 (AC_TYPE_UNSIGNED_LONG_LONG_INT): Likewise.
>   * m4/longlong.m4 (gl_AC_TYPE_LONG_LONG): Now just call
>   AC_TYPE_LONG_LONG_INT.  This macro is obsolete and will go soon.
>   * m4/ulonglong.m4 (gl_AC_TYPE_UNSIGNED_LONG_LONG) Likewise.

Well, this is a semantic change. It causes the vasnprintf, gettext, allocsa,
strtoimax and maybe other modules to ignore the 'long long' type if it has
less than 64 bits - on some older platforms that are not C99 compliant.

Likewise if you want to push this into autoconf. Autoconf documents this
macro

 -- Macro: AC_TYPE_LONG_LONG_INT
 If the C compiler supports a working `long long int' type, define
 `HAVE_LONG_LONG_INT'.

Requiring at least 64 bits would be a change in semantics. Likely to break
programs.

The difference matters: vasnprintf needs to understand the "ll" or "L" size
specifier, if the platform has a 'long long' type, regardless whether it
is 64-bit (ISO C 99 compliant) or not (likely only 32-bit). If your change
doesn't introduce a bug in vasnprintf, as I can tell after looking at the
code for 10 minutes, it's because the way the code is written and by luck.

So I propose to revert longlong.m4 and ulonglong.m4 to their previous state,
and move your new macros to files longlong64.m4, ulonglong64.m4, or integrate
them into stdint.m4.

Bruno

Re: [bug-gnulib] Re: simplification rewrite of stdint module installed into gnulib

[Bruno Haible]

Paul Eggert wrote:
> How about if we remove the mention of  instead?  On
> Solaris 8  states that programs "should not directly
> include this file" and I expect Solaris 7 is similar.

On Solaris 7,  is included by ,
, , .

Since our replacement  always include , which
always includes , your proposed change is fine: there
is no risk of conflict with  or .

Bruno

Re: [bug-gnulib] version-etc output format

[Bruno Haible]

Gary V. Vaughan wrote:
>   $ ./src/m4 --version
>   GNU M4 1.9a
>   Copyright (C) 2006 Free Software Foundation, Inc.
>   This is free software.  You may redistribute copies of it under the terms of
>   the GNU General Public License .
>   There is NO WARRANTY, to the extent permitted by law.
> 
>   Written by Rene' Seindal and Gary V. Vaughan.

The --version output of gettext, iconv, gperf, tar, patch etc. looks
the same, therefore some people may not consider it "ugly".

Bruno

Re: new module for temporary files in temporary directories

[Ben Pfaff]

Bruno Haible <[EMAIL PROTECTED]> writes:

> 1) The practical reason is that while developing libsigsegv, I noticed that
> C does not have the notion of a "barrier": In code like this:
>
>   set_up_datastructures();
>   /* HERE I would like a barrier */
>   signal(sig,my_signal_handler);
>
> I would like a barrier to ensure that all memory stores of
> set_up_datastructures()  have been performed before the signal handler
> is activated. __asm__("" : : : "memory"); is not portable (works only with
> GCC). Calls to an empty global function are optimized away by GCC 4. [...]

Is it safe to use an external function that is only defined in a
separate translation unit?  For example, to define an empty
function in a source file all by itself, then use a call to it as
a barrier.  This introduces a barrier in the common situations
that I know about, although there is the small overhead of a
call-and-return sequence.  (Are there compilers or linkers that
do inter-module optimization?)
-- 
"Term, holidays, term, holidays, till we leave school,
 and then work, work, work till we die."
C. S. Lewis

Re: [bug-gnulib] barriers and volatile

[Bruno Haible]

Ben Pfaff wrote:
> Is it safe to use an external function that is only defined in a
> separate translation unit?  For example, to define an empty
> function in a source file all by itself, then use a call to it as
> a barrier.

With more and more optimisations being pushed into the linker, this
doesn't look safe for the long term.

> (Are there compilers or linkers that do inter-module optimization?)

GCC 4.0 already does, when you pass several source files together on the
command line, and specify the option '-combine'.

Bruno

Re: [bug-gnulib] strndup module and crosscompiling

[Martin Lambers]

On Tue, 04. Jul 2006, 18:31:21 +0200, Bruno Haible wrote:
> Martin Lambers wrote:
> > gnulib/m4/strndup.m4 checks for a deficient strndup() function. When
> > crosscompiling, it assumes that strndup() is broken if the target is AIX
> > and that it is ok otherwise. 
> > 
> > This fails when crosscompiling to a target that has no strndup()
> > function at all, such as MinGW: HAVE_STRNDUP will wrongly be defined to
> > 1.
> 
> Thanks for reporting this. Does this patch work?

Yes, thanks a lot!

Martin

Re: coreutils merge into gnulib

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Eric Blake on 7/3/2006 11:49 AM:
> Mark D. Baushke  gnu.org> writes:
> 
>> The modules/dirname seems to now depend on xstrndup
> 
> Yes.  My original proposal for the change to dirname (was it last November?) 
> added this dependency; coreutils was already using xstrndup so Paul missed it.

In fact, my original proposal also added a dirname-tests module, to make
up for removing the test from dirname.c.  I'm committing this:

ChangeLog:
2006-07-04  Eric Blake  <[EMAIL PROTECTED]>

* modules/dirname-tests: New test module.
* tests/test-dirname.c: New file, replacing dirname.c
TEST_DIRNAME section that was recently deleted.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEqr//84KuGfSFAYARAtCOAJ9Mjz4ZtSa41GJ8AokhEgaZwkv1bgCglsWz
eaLDe7t1KwUqhBQSk2E421A=
=HnoS
-END PGP SIGNATURE-
Index: modules/dirname-tests
===
RCS file: modules/dirname-tests
diff -N modules/dirname-tests
--- /dev/null   1 Jan 1970 00:00:00 -
+++ modules/dirname-tests   4 Jul 2006 19:19:05 -
@@ -0,0 +1,12 @@
+Files:
+tests/test-dirname.c
+
+Depends-on:
+strdup
+
+configure.ac:
+
+Makefile.am:
+TESTS += test-dirname
+noinst_PROGRAMS += test-dirname
+test_dirname_SOURCES = test-dirname.c
Index: tests/test-dirname.c
===
RCS file: tests/test-dirname.c
diff -N tests/test-dirname.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ tests/test-dirname.c4 Jul 2006 19:19:05 -
@@ -0,0 +1,196 @@
+/* Test the gnulib dirname module.
+   Copyright (C) 2005 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   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.  */
+
+#ifdef HAVE_CONFIG_H
+# include 
+#endif
+
+#include "dirname.h"
+
+#include 
+#include 
+#include 
+#include 
+
+#include "strdup.h"
+
+const char *program_name = "test-dirname";
+
+struct test {
+  const char *name;/* Name under test.  */
+  const char *dir; /* dir_name (name).  */
+  const char *last;/* last_component (name).  */
+  const char *base;/* base_name (name).  */
+  const char *stripped;/* name after strip_trailing_slashes (name).  */
+  bool modified;/* result of strip_trailing_slashes (name).  */
+  bool absolute;   /* IS_ABSOLUTE_FILE_NAME (name).  */
+};
+
+static struct test tests[] = {
+  {"d/f",  "d","f","f","d/f",  false,  false},
+  {"/d/f", "/d",   "f","f","/d/f", false,  true},
+  {"d/f/", "d","f/",   "f/",   "d/f",  true,   false},
+  {"d/f//","d","f//",  "f/",   "d/f",  true,   false},
+  {"f",".","f","f","f",false,  false},
+  {"/","/","", "/","/",false,  true},
+#if DOUBLE_SLASH_IS_DISTINCT_ROOT
+  {"//",   "//",   "", "//",   "//",   false,  true},
+  {"//d",  "//",   "d","d","//d",  false,  true},
+#else
+  {"//",   "/","", "/","/",true,   true},
+  {"//d",  "/","d","d","//d",  false,  true},
+#endif
+  {"///",  "/","", "/","/",true,   true},
+  {"///a///",  "/","a///", "a/",   "///a", true,   true},
+  /* POSIX requires dirname("") and basename("") to both return ".",
+ but dir_name and base_name are defined differently.  */
+  {"", ".","", "", "", false,  false},
+  {".",".",".",".",".",false,  false},
+  {"..",   ".","..",   "..",   "..",   false,  false},
+#if FILE_SYSTEM_BACKSLASH_IS_FILE_NAME_SEPARATOR
+  {"a\\",  ".","a\\",  "a\\",  "a",true,   false},
+  {"a\\b", "a","b","b","a\\b", false,  false},
+  {"\\",   "\\",   "", "\\",   "\\",   false,  true},
+  {"\\/\\","\\",   "", "\\",   "\\",   true,   true},
+  {"/","\\",   "", "\\",   "\\",   true,   true},
+  {"\\//", "\\",   "", "\\",   "\\",   true,   true},
+  {"//\\", "/","", "/","/",true,   true},
+#else
+  {"a\\",  ".","a\\",  "a\\",

Re: version-etc output format

[Paul Eggert]

"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:

> Can we change swap the author and copyright blocks
> in version-etc.c to match coreutils and others output?

Actually, coreutils uses the new version-etc.c format nowadays
(this is not surprising, since Jim Meyering maintains both):

   $ ls --version
   ls (GNU coreutils) 5.97
   Copyright (C) 2006 Free Software Foundation, Inc.
   This is free software.  You may redistribute copies of it under the terms of
   the GNU General Public License .
   There is NO WARRANTY, to the extent permitted by law.

   Written by Richard Stallman and David MacKenzie.

The GNU Coding Standards say that the copyright notice should be right
after the version number, and that it is OK to finish the output with
a list of the major authors, so version-etc.c is right in the GNU
mainstream here.

Re: new module for temporary files in temporary directories

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

> The rule of thumb is: If a data field can be written by the main program
> and read by the signal handler, or vice versa, it needs to be marked as
> 'volatile'.

OK, thanks for explaining it.  Though I think you meant that the field
needs to be accessed only via volatile lvalues, not that the field
itself has to be volatile (an idea that cannot be combined with malloc).

> Data fields which are read-only from the moment they are entered
> into the data structure (such as the contents of strings) are not marked
> 'volatile'; I hope 'volatile' is not needed here.

Me too, though the ice is pretty thin here; please see below.

> 2) Another example is when a new list element is added to a list that
> is accessed from the signal handler. If the compiler would reorder the
> memory stores such that the list element is added to the list before it
> is fully initialized, the signal handler would likely crash.

Doesn't this contradict the previous remark "Data fields which are
read-only from the moment they are entered"?  Hence it suggests that
even these read-only data fields must be accessed only via volatile
lvalues.  So, to be safe, you'd have to declare them to be volatile as
well, which will infect more of the code with "volatile".  (But again,
please see below.)


> 3) The theoretical reason is that in ISO C, section 5.1.2.3.(5)
> guarantees to me that memory stores have been performed at sequence points
> only if I mark them 'volatile'.

I think that's a misunderstanding of that section.

>From the C standard's point of view, a volatile object (not merely an
object accessed via a volatile lvalue, but a volatile object, e.g.,
"static int volatile x;") has externally visible behavior.  You can
think of such objects as having little oscilloscope probes attached to
them, so that the user can observe every access to them, just as the
user can observe data written to output files.  This is not true of
ordinary objects accessed via volatile lvalues (which is what the new
module mostly uses); only volatile objects can be observed by the
user.

5.1.2.3.(5) talks only about volatile objects; it does not place any
constraints on accesses to ordinary objects via volatile lvalues.

> (I don't understand what 5.1.2.3.(4) is
> talking about since GCC 4 takes the freedom to reorder memory loads and
> stores arbitrarily across sequence points, if it can prove that there is
> no aliasing.)

That part of the C standard is often misunderstood.  The C standard
requires that the only object accesses that signal handlers may do
(other than to local variables) is to assign to "sig_atomic_t
volatile" objects.  If your signal handler does any other object
accesses, or if it calls any function other than _Exit or signal or
abort, behavior is undefined.  GCC 4 is entitled to do the
optimizations in question, so long as it respects this (which is
usually fairly easy to do).

Every optimizing C implementation that I know of takes advantage of
this gaping loophole, which means that for the kind of programming the
temporary-file module is trying to do, behavior is pretty much
undefined all around.

If your signal handler conforms to C, then you can rely on
5.1.2.3.(4)'s guarantees about objects' values during an interrupt.
This is true even for nonvolatile objects -- except that, because your
signal handler cannot access these nonvolatile objects, you cannot
check the guarantees!  (Tricky, huh?)

> To me, "volatile" means: "Perform the memory access here and now, without
> merging several memory accesses, without changing the memory word size
> width, and without reordering."

That's not what the standard says, I'm afraid.  For volatile
_objects_, accesses must be done before the next sequence point, but
otherwise merging, reordering, and wordsize change is allowed for
volatile objects.  Worse, volatile _lvalues_ provide no more
guarantees than ordinary lvalues when the underlying objects are not
volatile.  And in either case, programs must use only extremely
limited signal handlers in order to get defined behavior.

For this reason, I'm becoming more inclined to not use volatile
lvalues, and to rely only on volatile objects.  This is not because I
think volatile objects suffice; it's only because I doubt whether
adding "volatile" to lvalues helps, and it certainly clutters up the
code (and has my readers wonder what's going on :-).

Lest it be thought that this is merely an academic exercise:

We used to have lots of problems with signals and 'ls'.  For example,
a SIGTSTP signal can arrive at any time, and it used to cause "ls" to
output a command sequence to change the terminal back to the default
color.  But this command sequence could appear in the middle of a
multibyte character, or in the middle of another color-change
sequence; either event could mess up the screen.

In 
I fixed this problem by rewriting 'ls' to use alm

Re: new module for temporary files in temporary directories

[Ben Pfaff]

Paul Eggert <[EMAIL PROTECTED]> writes:

> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> 3) The theoretical reason is that in ISO C, section 5.1.2.3.(5)
>> guarantees to me that memory stores have been performed at sequence points
>> only if I mark them 'volatile'.
>
> I think that's a misunderstanding of that section.
>
> From the C standard's point of view, a volatile object (not merely an
> object accessed via a volatile lvalue, but a volatile object, e.g.,
> "static int volatile x;") has externally visible behavior.  You can
> think of such objects as having little oscilloscope probes attached to
> them, so that the user can observe every access to them, just as the
> user can observe data written to output files.  This is not true of
> ordinary objects accessed via volatile lvalues (which is what the new
> module mostly uses); only volatile objects can be observed by the
> user.
>
> 5.1.2.3.(5) talks only about volatile objects; it does not place any
> constraints on accesses to ordinary objects via volatile lvalues.

This is a particularly pessimistic interpretation of the
standard, and I do not agree with it.  The standard is careful to
distinguish between objects of a type and objects *defined* with
a particular type.  An object having a type is just ascribing a
relatively arbitrary type to a memory region, as you can see from
the relevant definitions in C99:

 3.14
1object
 region of data storage in the execution environment, the
 contents of which can represent values
2NOTE When referenced, an object may be interpreted as having a
 particular type; see 6.3.2.1.

...

 6.3.2 Other operands
 6.3.2.1  Lvalues, arrays, and function designators
1An lvalue is an expression with an object type or an incomplete
 type other than void;53) if an lvalue does not designate an
 object when it is evaluated, the behavior is undefined.
 When an object is said to have a particular type, the type
 is specified by the lvalue used to designate the object.

Note in particular the final sentence above: the type used for an
object is a function of the lvalue.

An object *defined* as a type means that there is a declaration
that says it has the type, as in your "static int volatile x;"
example.

The standard carefully distinguishes these forms of reference.
For example, 6.7.3p5 talks about the *defined* type of an object:

 If an attempt is made to refer to an object defined with a
   
 volatile-qualified type through use of an lvalue with
 ^^^
 non-volatile-qualified type, the behavior is undefined.113)

But 5.1.2.3p5 talks about the type of an object, with no
reference to how the object was defined:

 The least requirements on a conforming implementation are:

 - At sequence points, volatile objects are stable in the
   
   sense that previous accesses are complete and subsequent
   accesses have not yet occurred.

The C99 rationale makes this clear, in 6.7.3p10, although the
wording is looser (I do not think that the rationale receives the
same level of review as the standard itself):

  If it is necessary to access a non-volatile object using
  volatile semantics, the technique is to cast the address of
  the object to the appropriate pointer-to-qualified type,
  then dereference that pointer.
-- 
Ben Pfaff 
email: [EMAIL PROTECTED]
web: http://benpfaff.org

Re: simplification rewrite of stdint module installed into gnulib

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

>  -- Macro: AC_TYPE_LONG_LONG_INT
>  If the C compiler supports a working `long long int' type, define
>  `HAVE_LONG_LONG_INT'.
>
> Requiring at least 64 bits would be a change in semantics.

Yes.  Whether this is a good thing depends on what one means by
"working".

For quite some time, the coreutils/gnulib long-long checker has
rejected a 'long long' implementation that does not support long-long
division or remainder (which are limitations of some pre-C99
implementations).  So if we have code that relies on HAVE_LONG_LONG
meaning "the type 'long long' exists", such code is already broken.

> The difference matters: vasnprintf needs to understand the "ll" or "L" size
> specifier, if the platform has a 'long long' type, regardless whether it
> is 64-bit (ISO C 99 compliant) or not (likely only 32-bit).

I must be missing something, since programs that don't think "long
long" works shouldn't use the "ll" size specifier.  And portable
programs should use "L" only for floating-point conversion.

Or is the problem that different parts of your program might disagree
about whether 'long long' works?  Surely the solution is to get on the
same page with respect to whether 'long long' works, as this would in
general be needed in in any event.

> If your change doesn't introduce a bug in vasnprintf, as I can tell
> after looking at the code for 10 minutes, it's because the way the
> code is written and by luck.

I hope our luck holds.  But how serious is the issue?  What platforms
have 32-bit long long?  Traditionally, 'long long' has always been at
least 64 bits.  That was the point of 'long long', and by now many
applications must assume it, so I suspect that in practice we will
solve more problems than we cure by requiring 'long long' to be 64
bits.

For what it's worth, the gnulib macro was originally intended to check
for 64-bittedness as well (hence the 63-bit shift).  I think that
check was inadvertently dropped when it was changed from a run-time to
a link-time test.