mainAutoconf - Support: sr #110298, "Substitute and define...

 
 

sr #110298: "Substitute and define special characters" test fails on NetBSD

Submitter:  Zack Weinberg <zackw>
Submitted:  Wed 26 Aug 2020 09:28:46 PM UTC
   
 
Priority:  * 2 - Eventually Severity:  3 - Normal
Status:  Confirmed Privacy:  Public
Assigned to:  None Open/Closed:  Open
Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 08 Dec 2023 01:51:02 PM UTC, comment #4: 

Needs a volunteer, ideally someone used to working with NetBSD and its development team, who can determine the root cause, find a workaround if possible, and push changes to NetBSD as necessary.

Zack Weinberg <zackw>
Group administrator
Sat 28 Nov 2020 03:27:23 PM UTC, comment #3: 

Setting LC_ALL=C or LC_ALL=en_US.ISO-8859-1 in the environment of tests/testsuite does not change anything.  m4sugar scripts unconditionally set LC_ALL=C on startup anyway.

Zack Weinberg <zackw>
Group administrator
Wed 26 Aug 2020 10:03:46 PM UTC, comment #2: 

POSIX suggests that the test relies on unspecified (undefined?) behavior if the output of the printf shell command is not properly encoded for the current locale.

Have you tried running the test with LC_ALL="C" in the environment? If that works around the problem, then we can set LC_ALL="C" for that test (we perhaps need to do that anyway...).

Paul Eggert <eggert>
Group administrator
Wed 26 Aug 2020 09:34:00 PM UTC, comment #1: 

The same failure occurs with 2.69 and its testsuite, so it's not a regression. This is probably some sort of issue with the system tools on NetBSD 9 not being completely 8-bit clean and unprintable-character-transparent. Low priority.

(N.B. it's test #245 in the older testsuite.)

Zack Weinberg <zackw>
Group administrator
Wed 26 Aug 2020 09:28:46 PM UTC, original submission:  


255. torture.at:883: testing Substitute and define special characters ...
./torture.at:950: autoconf --force
./torture.at:950: "$SHELL_N" -n configure
stderr:
./torture.at:951: autoheader
./torture.at:951: sort -o expout expout.in
./torture.at:951: sed -ne 's/^[  ]*#[    ]*undef[        ][      ]*//p' \
           $config_h_in | sort
./torture.at:956: ./configure $configure_options $awk_arg
stdout:
checking for gawk... gawk
configure: creating ./config.status
config.status: creating Foo
config.status: creating Zardoz
config.status: creating config.h
./torture.at:957: cat Foo
./torture.at:970: cmp allowed-chars Zardoz
--- /dev/null   2020-08-26 15:33:08.643785762 -0400
+++ /net/u/1/z/zackw/autoconf-2.69b.53-df186-dirty/tests/testsuite.dir/at-groups/255/stdout     2020-08-26 15:33:09.029839000 -0400
@@ -0,0 +1 @@
+allowed-chars Zardoz differ: char 256, line 2
./torture.at:970: exit code was 1, expected 0


Examining config.status I see that the value for S["zardoz"] is already wrong:


00000000: 535b 227a 6172 646f 7a22 5d3d 2201 7302  S["zardoz"]=".s.
00000010: 7303 7304 7305 7306 7307 7308 7309 735c  s.s.s.s.s.s.s.s\
00000020: 6e22 5c0a 2273 0b73 0c73 0e73 0f73 1073  n"\."s.s.s.s.s.s
00000030: 1173 1273 1373 1473 1573 1673 1773 1873  .s.s.s.s.s.s.s.s
00000040: 1973 1a73 1b73 1c73 1d73 1e73 1f73 2073  .s.s.s.s.s.s.s s
00000050: 2173 5c22 7323 7324 7325 7326 7327 7328  !s\"s#s$s%s&s's(
00000060: 7329 732a 732b 732c 732d 732e 732f 7330  s)s*s+s,s-s.s/s0
00000070: 7331 7332 7333 7334 7335 7336 7337 7338  s1s2s3s4s5s6s7s8
00000080: 7339 733a 733b 733c 733d 733e 733f 7340  s9s:s;s<s=s>s?s@
00000090: 7341 7342 7343 7344 7345 7346 7347 7348  sAsBsCsDsEsFsGsH
000000a0: 7349 734a 734b 734c 734d 734e 734f 7350  sIsJsKsLsMsNsOsP
000000b0: 7351 7352 7353 7354 7355 225c 0a22 7356  sQsRsSsTsU"\."sV
000000c0: 7357 7358 7359 735a 735b 735c 5c73 5d73  sWsXsYsZs[s\\s]s
000000d0: 5e73 5f73 6073 6173 6273 6373 6473 6573  ^s_s`sasbscsdses
000000e0: 6673 6773 6873 6973 6a73 6b73 6c73 6d73  fsgshsisjskslsms
000000f0: 6e73 6f73 7073 7173 7273 7373 7473 7573  nsospsqsrssstsus
00000100: 7673 7773 7873 7973 7a73 7b73 7c73 7d73  vswsxsyszs{s|s}s
00000110: 7e73 7f73 8073 8181 7381 8273 8183 7381  ~s.s.s..s..s..s.  **
00000120: 8473 8185 7381 8673 8187 7381 8873 8189  .s..s..s..s..s..  **
00000130: 7381 8a73 818b 738c 738d 738e 738f 7390  s..s..s.s.s.s.s.  **
00000140: 7391 7392 7393 7394 7395 7396 7397 7398  s.s.s.s.s.s.s.s.
00000150: 7399 7322 5c0a 229a 739b 739c 739d 739e  s.s"\.".s.s.s.s.
00000160: 739f 73a0 73a1 73a2 73a3 73a4 73a5 73a6  s.s.s.s.s.s.s.s.
00000170: 73a7 73a8 73a9 73aa 73ab 73ac 73ad 73ae  s.s.s.s.s.s.s.s.
00000180: 73af 73b0 73b1 73b2 73b3 73b4 73b5 73b6  s.s.s.s.s.s.s.s.
00000190: 73b7 73b8 73b9 73ba 73bb 73bc 73bd 73be  s.s.s.s.s.s.s.s.
000001a0: 73bf 73c0 73c1 73c2 73c3 73c4 73c5 73c6  s.s.s.s.s.s.s.s.
000001b0: 73c7 73c8 73c9 73ca 73cb 73cc 73cd 73ce  s.s.s.s.s.s.s.s.
000001c0: 73cf 73d0 73d1 73d2 73d3 73d4 73d5 73d6  s.s.s.s.s.s.s.s.
000001d0: 73d7 73d8 73d9 73da 73db 73dc 73dd 73de  s.s.s.s.s.s.s.s.
000001e0: 73df 73e0 73e1 73e2 73e3 7322 5c0a 22e4  s.s.s.s.s.s"\.".
000001f0: 73e5 73e6 73e7 73e8 73e9 73ea 73eb 73ec  s.s.s.s.s.s.s.s.
00000200: 73ed 73ee 73ef 73f0 73f1 73f2 73f3 73f4  s.s.s.s.s.s.s.s.
00000210: 73f5 73f6 73f7 73f8 73f9 73fa 73fb 73fc  s.s.s.s.s.s.s.s.
00000220: 73fd 73fe 7322 0a                        s.s.s".


The incorrect segment of this hexdump is marked with asterisks in the right margin.  Each byte from 0x81 through 0x8b, inclusive, has had an extra 0x81 prepended.

This has not happened in the config.log output-variable dump, so I suspect the bug is somewhere in the process of constructing the "subs.awk" section of config.status, but there's a lot of steps in there and I haven't dug into it any further.

Zack Weinberg <zackw>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by eggert (Posted a comment)
  • -email is unavailable- added by zackw (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-12-08 zackw Priority1 - Blocked 2 - Eventually
    2020-08-26 zackw Priority5 - Unprioritized 1 - Blocked
        StatusNone Confirmed

    Back to the top

    Powered by Savane 3.14-8eb0.
    Corresponding source code