Re: special characters in filenames in error messages

[Bruno Haible]

Hello Karl,

> new proposal is to use octal escapes \ooo (and
> nothing else).  Specifically:
> 
> 1) if the first character of the source is a ", the source name extends
>to the next ".  (Including :'s, for example.)
> 2) within that "...", \ooo is recognized.  For instance, \042=" and \134=\,
>so this weird filename (5 chars):
> a:"\b
>would be output in an error message as:
> "a:\042\134b":10:some message
> 
> This should be about as easy to parse as it can be, and it follows rms's
> "one character one specification" rule.
> 
> The \ooo convention could be used for any character, but in an 8-bit
> clean environment, I believe it is only *required* for " and \.

1) For which filenames should the escaped syntax be used and for which not?

   From the syntax you gave, and assuming a program that parses line by line,
   it is *required* only if the filename

 - contains a ':' or newline, or
 - starts with a '"'.

   Is that the intent?

   Or is the intent that it be used for a wider class of frequently used
   filenames, such as
 - filenames that contain non-ASCII characters? (I hope not, this would
   punish people who use their native script for filenames.)
 - filenames that contain a space? (I hope not, since these are very
   frequent.)

2) Native Windows filenames (which occur in mingw ports of GNU programs)
   often contain a colon and backslashes: 'C:\SUBDIR\0049\FOOBAR.PNG'
   It would be useful, in my opinion, to use a syntax that preserves the
   human-readability and copy&paste-ability of such filenames.

   I.e. I would like to see above filename being escaped as
   "C:\SUBDIR\0049\FOOBAR.PNG". But this is incompatible with the use
   of \nnn as escape sequence.

   Since the use of % in filenames is less frequent than the backslash
   (on Windows), and since there is already an RFC standard for how to
   escape URIs (), I would vote
   for using the %nn syntax.

   So my proposal is:

   - For parsing:
 - If the first character is a '"', then the escaped syntax is
   in use. The filename is enclosed in "..."; inside,
 - occurrences of '"' and '%' are escaped as %22 and %25,
   respectively,
 - other ASCII characters may be escaped in %nn syntax as well,
   where nn is the hexadecimal notation (case insignificant)
   of the byte value in the ASCII encoding.
 - Otherwise, the filename ends at the first ':' or end of line.

   - For output:
 The escaped syntax is required if the filename contains a ':' or
 newline, or starts with a '"'. It may also be used for other
 filenames.

Bruno

Re: special characters in filenames in error messages

[Bruno Haible]

Hello Karl,

> new proposal is to use octal escapes \ooo (and
> nothing else).  Specifically:
> 
> 1) if the first character of the source is a ", the source name extends
>to the next ".  (Including :'s, for example.)
> 2) within that "...", \ooo is recognized.  For instance, \042=" and \134=\,
>so this weird filename (5 chars):
> a:"\b
>would be output in an error message as:
> "a:\042\134b":10:some message
> 
> This should be about as easy to parse as it can be, and it follows rms's
> "one character one specification" rule.
> 
> The \ooo convention could be used for any character, but in an 8-bit
> clean environment, I believe it is only *required* for " and \.

1) For which filenames should the escaped syntax be used and for which not?

   From the syntax you gave, and assuming a program that parses line by line,
   it is *required* only if the filename

 - contains a ':' or newline, or
 - starts with a '"'.

   Is that the intent?

   Or is the intent that it be used for a wider class of frequently used
   filenames, such as
 - filenames that contain non-ASCII characters? (I hope not, this would
   punish people who use their native script for filenames.)
 - filenames that contain a space? (I hope not, since these are very
   frequent.)

2) Native Windows filenames (which occur in mingw ports of GNU programs)
   often contain a colon and backslashes: 'C:\SUBDIR\0049\FOOBAR.PNG'
   It would be useful, in my opinion, to use a syntax that preserves the
   human-readability and copy&paste-ability of such filenames.

   I.e. I would like to see above filename being escaped as
   "C:\SUBDIR\0049\FOOBAR.PNG". But this is incompatible with the use
   of \nnn as escape sequence.

   Since the use of % in filenames is less frequent than the backslash
   (on Windows), and since there is already an RFC standard for how to
   escape URIs (), I would vote
   for using the %nn syntax.

   So my proposal is:

   - For parsing:
 - If the first character is a '"', then the escaped syntax is
   in use. The filename is enclosed in "..."; inside,
 - occurrences of '"' and '%' are escaped as %22 and %25,
   respectively,
 - other ASCII characters may be escaped in %nn syntax as well,
   where nn is the hexadecimal notation (case insignificant)
   of the byte value in the ASCII encoding.
 - Otherwise, the filename ends at the first ':' or end of line.

   - For output:
 The escaped syntax is required if the filename contains a ':' or
 newline, or starts with a '"'. It may also be used for other
 filenames.

Bruno

_AC_LANG_OPENMP and m4_copy

[Ralf Wildenhues]

When I try to `./autogen.sh --quick' CVS gettext, using git Autoconf,
things fall over like this (several instances):

| gnulib-m4/openmp.m4:29: error: m4_copy: won't overwrite defined macro: 
_AC_LANG_OPENMP(C++)
| gnulib-m4/openmp.m4:29: the top level
| autom4te: /usr/bin/m4 failed with exit status: 1
| aclocal: autom4te failed with exit status: 1

I'm not quite sure whether an Autoconf bug/incompatibility is involved
here (therefore the Cc: to bug-autoconf).  m4_copy wasn't documented in
earlier Autoconf releases, but there may still have been problematic
semantic changes, I don't know.

Anyway, the following patch seems to fix it.  OK to apply?

Cheers,
Ralf

2008-12-03  Ralf Wildenhues  <[EMAIL PROTECTED]>

* m4/openmp.m4 (AC_OPENMP): Do not define with Autoconf 2.62 or
newer.

diff --git a/m4/openmp.m4 b/m4/openmp.m4
index 8fd510b..bd78809 100644
--- a/m4/openmp.m4
+++ b/m4/openmp.m4
@@ -1,11 +1,13 @@
-# openmp.m4 serial 4
-dnl Copyright (C) 2006-2007 Free Software Foundation, Inc.
+# openmp.m4 serial 5
+dnl Copyright (C) 2006-2008 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 can be removed once we assume autoconf >= 2.62.
 
+m4_version_prereq([2.62],, [
+
 # _AC_LANG_OPENMP
 # ---
 # Expands to some language dependent source code for testing the presence of
@@ -90,3 +92,5 @@ AC_DEFUN([AC_OPENMP],
   fi
   AC_SUBST([OPENMP_]_AC_LANG_PREFIX[FLAGS])
 ])
+
+])

Re: _AC_LANG_OPENMP and m4_copy

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Ralf Wildenhues on 12/3/2008 1:01 PM:
> When I try to `./autogen.sh --quick' CVS gettext, using git Autoconf,
> things fall over like this (several instances):
> 
> | gnulib-m4/openmp.m4:29: error: m4_copy: won't overwrite defined macro: 
> _AC_LANG_OPENMP(C++)
> | gnulib-m4/openmp.m4:29: the top level
> | autom4te: /usr/bin/m4 failed with exit status: 1
> | aclocal: autom4te failed with exit status: 1
> 
> I'm not quite sure whether an Autoconf bug/incompatibility is involved
> here (therefore the Cc: to bug-autoconf).  m4_copy wasn't documented in
> earlier Autoconf releases, but there may still have been problematic
> semantic changes, I don't know.

There was a semantic change - in 2.63, m4_copy used to only copy the
most-recent pushdef definition of the source and overwrite any most-recent
definition of the destination; and worse, m4_rename completely threw away
the rest of the pushdef stack of the source.  The new documented semantics
copy the entire pushdef stack of definitions (so that m4_rename doesn't
lose definitions), and requires that the destination be undefined (use
m4_ifdef([dest],[m4_undefine([dest])]) beforehand if this is a problem).

> 
> Anyway, the following patch seems to fix it.  OK to apply?

Looks fine to me, but let Bruno chime in before committing.  I agree with
your approach of fixing gnulib to avoid the problem by not competing when
a new-enough autoconf provides the macro, and I don't think we need to
change the new semantics of m4_copy.

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

Eric Blake [EMAIL PROTECTED]
-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

iEYEARECAAYFAkk26nkACgkQ84KuGfSFAYA9HgCeJusSru85OVUwnCuAptawRJFH
azkAn3JUJOPRoyQ0qNQ0016IvP25Vl8j
=njNh
-END PGP SIGNATURE-

Re: special characters in filenames in error messages

[Karl Berry]

   it is *required* only if the filename
 - contains a ':' or newline, or
 - starts with a '"'.
   Is that the intent?

Yes.

   - For parsing:
 - If the first character is a '"', then the escaped syntax is
   in use. The filename is enclosed in "..."; inside,
 - occurrences of '"' and '%' are escaped as %22 and %25,
   respectively,
 - other ASCII characters may be escaped in %nn syntax as well,
   where nn is the hexadecimal notation (case insignificant)
   of the byte value in the ASCII encoding.
 - Otherwise, the filename ends at the first ':' or end of line.

Ok, I agree about using %nn instead of \ooo.  Your point about Windows
filenames and \'s seems valid to me.

   - For output:
 The escaped syntax is required if the filename contains a ':' or
 newline, or starts with a '"'. It may also be used for other
 filenames.

I agree.

So, barring further comments/suggestion, I'll propose that to rms in the
next couple of days.

Thanks very much.

karl

Re: _AC_LANG_OPENMP and m4_copy

[Bruno Haible]

Hello Ralf,

Thanks for the report and fix.

Eric Blake wrote:
> Looks fine to me, but let Bruno chime in before committing.  I agree with
> your approach of fixing gnulib to avoid the problem by not competing when
> a new-enough autoconf provides the macro

I agree with this approach. But the patch introduces the use of another
undocumented macro, namely 'm4_version_prereq'. I prefer to get away without
it, and am committing this:


2008-12-03  Ralf Wildenhues  <[EMAIL PROTECTED]>
Bruno Haible  <[EMAIL PROTECTED]>

* m4/openmp.m4 (AC_OPENMP): Do not define with Autoconf 2.62 or newer.

--- m4/openmp.m4.orig   2008-12-04 01:24:00.0 +0100
+++ m4/openmp.m42008-12-04 00:57:39.0 +0100
@@ -1,11 +1,15 @@
-# openmp.m4 serial 4
-dnl Copyright (C) 2006-2007 Free Software Foundation, Inc.
+# openmp.m4 serial 5
+dnl Copyright (C) 2006-2008 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 can be removed once we assume autoconf >= 2.62.
 
+dnl Expand to nothing in autoconf >= 2.62. m4_copy has a different
+dnl semantic in autoconf > 2.63.
+m4_ifdef([AC_OPENMP], [], [
+
 # _AC_LANG_OPENMP
 # ---
 # Expands to some language dependent source code for testing the presence of
@@ -90,3 +94,5 @@
   fi
   AC_SUBST([OPENMP_]_AC_LANG_PREFIX[FLAGS])
 ])
+
+])

Re: Bus error

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[adding bug-gnulib, as the owner of the c-stack module]

According to Thomas J. Duck on 12/3/2008 6:49 PM:
> 

Hello Thomas,

> 
>  I have installed m4-1.4.12 on my Mac OS X 10.4 system.  'Make
> check' results in the error below.  If there is any further information
> you need, please let me know. --Tom
> 
> Checking ./stackovf.test
> Stack soft limit set to 300K
> Failure - m4 aborted unexpectedly
> Output from m4:
> m4: internal error detected; please report this bug to <[EMAIL PROTECTED]>:
> Bus error

Thanks for the report.  Did you build with libsigsegv installed, and if
so, which version?  I know that older versions of libsigsegv are buggy on
MacOS, although I don't have access to a Mac machine myself.  On the other
hand, if this is without libsigsegv, then that represents a bug where
c-stack should be made more robust, if possible.

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

Eric Blake [EMAIL PROTECTED]
-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

iEYEARECAAYFAkk3O4oACgkQ84KuGfSFAYDglQCeKiVhI2faIYIH1HqJcsmNlxMx
EA8An0qAl1RnmssBcRTl7l2aTCiviZC/
=IsHP
-END PGP SIGNATURE-

Re: Bus error

[Thomas J. Duck]

Hi Eric,

 Thanks for your email -- the quickest response to a bug report  
ever!


 'locate libsigsegv' turns up nothing.

 If you have other tests that you would like me to run, please  
let me know.  I'm happy to help where I can.


Cheers,
Tom

--

On 3-Dec-08, at 10:08 PM, Eric Blake wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[adding bug-gnulib, as the owner of the c-stack module]

According to Thomas J. Duck on 12/3/2008 6:49 PM:




Hello Thomas,



 I have installed m4-1.4.12 on my Mac OS X 10.4 system.  'Make
check' results in the error below.  If there is any further  
information

you need, please let me know. --Tom

Checking ./stackovf.test
Stack soft limit set to 300K
Failure - m4 aborted unexpectedly
Output from m4:
m4: internal error detected; please report this bug to [EMAIL PROTECTED]>:

Bus error


Thanks for the report.  Did you build with libsigsegv installed,  
and if
so, which version?  I know that older versions of libsigsegv are  
buggy on
MacOS, although I don't have access to a Mac machine myself.  On  
the other

hand, if this is without libsigsegv, then that represents a bug where
c-stack should be made more robust, if possible.

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

Eric Blake [EMAIL PROTECTED]
-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

iEYEARECAAYFAkk3O4oACgkQ84KuGfSFAYDglQCeKiVhI2faIYIH1HqJcsmNlxMx
EA8An0qAl1RnmssBcRTl7l2aTCiviZC/
=IsHP
-END PGP SIGNATURE-


--

Thomas J. Duck <[EMAIL PROTECTED]>

Associate Professor,
Department of Physics and Atmospheric Science, Dalhousie University,
Halifax, Nova Scotia, Canada, B3H 3J5.
Tel: (902)494-1456 | Fax: (902)494-5191 | Lab: (902)494-3813
Web: http://aolab.phys.dal.ca/

Re: Bus error

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[please don't top-post]

According to Thomas J. Duck on 12/3/2008 7:29 PM:
> Hi Eric,
> 
>  Thanks for your email -- the quickest response to a bug report ever!
> 
>  'locate libsigsegv' turns up nothing.

It doesn't turn up anything for me, either, because it is not an
executable, but a library.  More to the point, you can find out if m4 is
using libsigsegv by inspecting your config.log output.  For example, when
I built a recent development copy of m4, my config.log contains:

configure:7054: checking for libsigsegv
configure:7082: result: yes
configure:7088: checking how to link with libsigsegv
configure:7090: result: -lsigsegv

and further searching turns up /usr/include/sigsegv.h which includes:

#define LIBSIGSEGV_VERSION 0x0204 /* version number: (major<<8) + minor */

so my machine has libsigsegv 2.4 installed (no known bugs when used on
cygwin, but according to the NEWS file, this version is buggy on at least
Mac, BSD, and Linux; 2.6 is the most recent release, but even that still
has bugs on fringe platforms like Irix that are only fixed in CVS libsigsegv).

> 
>  If you have other tests that you would like me to run, please let
> me know.  I'm happy to help where I can.

Are you comfortable using gdb (assuming you have that installed)?  Are you
able to figure out how to run the failing test under gdb such that you can
give a stack trace at the point where the SIGBUS occurred, or would you
like a step-by-step walkthrough?

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

Eric Blake [EMAIL PROTECTED]
-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

iEYEARECAAYFAkk3SO0ACgkQ84KuGfSFAYCx2ACeJ0qnSiRu4N3xMI5p79iog4Wa
KuAAn03GZ11VTmxFOlAZlDpbQveOGdQZ
=baiT
-END PGP SIGNATURE-

Re: special characters in filenames in error messages

[Paolo Bonzini]

Karl Berry wrote:
> > I don't see why \n should be special?
> 
> For the same reason why we should escape :, i.e. to ensure that each
> line can be interpreted as FILE:LINE:MESSAGE.
> 
> Obviously we have to escape newline characters.  In the original
> proposal, they would be escaped as \012.  I thought you were proposing
> to use a special-case \n instead.  So I asked what is gained by doing it
> that way.

Ah, I was referring to \n because my proposal included using standard C
escape sequences.  But if that's not done, of course \012 or \x0A is fine.

Paolo