[sr #110554] AC_CONFIG_HEADERS doesn't work properly for files with Windows line-endings

2023-12-18 Thread Zack Weinberg
Update of sr#110554 (group autoconf):

Priority: 7 - Release N (Desirable) => 3 - Release N+1
  Status:  Ready For Test => In Progress

___

Follow-up Comment #2:

Turns out either your change or my change will break config.status on Solaris
10, because its /usr/bin/awk is incredibly limited.  It has a "nawk" that is
more capable, but we'd have to notice that we need to use that, and
config.status isn't currently bothering.

With regret, this pushes this change over the line to 'too risky when I want
to make the release this Friday'.

Revert:



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/




Re: [sr #110554] AC_CONFIG_HEADERS doesn't work properly for files with Windows line-endings

2023-12-15 Thread Nick Bowler
On 2023-12-15 11:19, Zack Weinberg wrote:
[...]
> old non-GNU implementations of awk probably don't support using a
> regexp as the third argument to 'split'.  (I'm not 100% sure about
> this; the gawk manual is usually very good about pointing out
> portability issues but in this case it's ambiguous.

This fact is also explicitly mentioned in the Autoconf documentation[1]:

  In code portable to both traditional and modern Awk, FS must be a
  string containing just one ordinary character, and similarly for
  the field-separator argument to split.

The heirloom-tools package[2] includes a traditional awk with this
particular limitation.  This is a free software implementation (ported
from OpenSolaris) that can be installed on a modern GNU/Linux system.
It should be very similar to Solaris 10 /bin/awk:

  % echo abcdefg | heirloom-tools/5bin/awk '{ split($1, a, /c?e/); print a[2]; 
}'
  awk: syntax error near line 1

  % echo abcdefg | heirloom-tools/5bin/awk '{ split($1, a, "c?e"); print a[2]; 
}'
  defg

Even with AC_PROG_AWK, on ULTRIX it selects "nawk" which still does not
work with a regexp argument to split, but it does work if the argument
is a string which can be interpreted as a regexp:

  ultrix% echo abcdefg | nawk '{ split($1, a, /c?e/); print a[2]; }'
  [no output]

  ultrix% echo abcdefg | nawk '{ split($1, a, "c?e"); print a[2]; }'
  fg

[1] 
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/autoconf.html#Limitations-of-Usual-Tools
[2] https://heirloom.sourceforge.net/tools.html

Cheers,
  Nick



[sr #110554] AC_CONFIG_HEADERS doesn't work properly for files with Windows line-endings

2023-12-15 Thread Zack Weinberg
Update of sr#110554 (group autoconf):

  Status:   Confirmed => Ready For Test 

___

Follow-up Comment #1:

Should be fixed in
,
thanks for reporting.

Thanks also for providing a patch; it might have taken me hours to figure out
what to change otherwise.  I made a somewhat different change, though, because
your code could produce a config.h with _inconsistent_ line endings, and also
because old non-GNU implementations of awk probably don't support using a
regexp as the third argument to 'split'.  (I'm not 100% sure about this; the
gawk manual is usually very good about pointing out portability issues but in
this case it's ambiguous.  For code this fundamental I think it's best to play
safe.)

I don't have access to a development environment on a machine that uses CRLF
line endings.  I would appreciate it if you could test autoconf trunk in the
environment where you originally encountered the problem.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/




[sr #110554] AC_CONFIG_HEADERS doesn't work properly for files with Windows line-endings

2023-12-08 Thread Zack Weinberg
Update of sr#110554 (group autoconf):

  Status:None => Confirmed  


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/




[sr #110554] AC_CONFIG_HEADERS doesn't work properly for files with Windows line-endings

2023-12-08 Thread Zack Weinberg
Update of sr#110554 (group autoconf):

Priority:   5 - Unprioritized => 7 - Release N (Desirable)


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/




[sr #110554] AC_CONFIG_HEADERS doesn't work properly for files with Windows line-endings

2021-10-21 Thread David Allsopp
URL:
  

 Summary: AC_CONFIG_HEADERS doesn't work properly for files
with Windows line-endings
 Project: Autoconf
Submitted by: dra27
Submitted on: Thu 21 Oct 2021 04:20:43 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: Microsoft Windows

___

Details:

For headers with standard


#undef MACRO


lines, AC_CONFIG_HEADERS doesn't perform substitutions if the there is no
whitespace following MACRO and the .in file has Windows CRLF line-endings.

This is a mild nuisance, given that the C pre-processor shouldn't mind about
line endings. The work-around is to add space (or space and a comment) after
the macro name, but the fix seems relatively straightforward (assuming the
change is portable).


diff --git a/lib/autoconf/status.m4 b/lib/autoconf/status.m4
index c2721a85..d5c222bb 100644
--- a/lib/autoconf/status.m4
+++ b/lib/autoconf/status.m4
@@ -824,9 +824,9 @@ cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
   for (key in D) D_is_set[key] = 1
   FS = "^G"
 }
-/^[\t ]*#[\t ]*(define|undef)[\t ]+$ac_word_re([\t (]|\$)/ {
+/^[\t ]*#[\t ]*(define|undef)[\t ]+$ac_word_re([\t (]|\r?\$)/ {
   line = \$ 0
-  split(line, arg, " ")
+  split(line, arg, /[ \r\t]/)
   if (arg[1] == "#") {
 defundef = arg[2]
 mac1 = arg[3]





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/