[sr #110403] autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS

[Zack Weinberg]

Follow-up Comment #7, sr #110403 (project autoconf):

OK, I've verified that this is a bug in OmniOS /bin/sh.

OmniOS /bin/sh reads scripts in 8192-byte chunks.  If the last line of a
here-document straddles a chunk boundary, and the last character of that line
is not a backslash, but the last character of the first chunk _is_ a
backslash, and the first character of the second chunk is a dollar sign, then
the here-document will be written out without a final newline.  (I'm not sure
whether the boundary has to fall within the last line of the here-document, or
whether the first character of the second chunk has to be a dollar sign.  I
know \# doesn't work, though.)

The attached file t-001fa2.sh.gz is a self-contained reproducer for the bug. 
If you uncompress it and run it with a shell that has this bug, it will print
something like this:


cmp: EOF on /tmp/tmp.LCyimJxG8v after byte 1, in line 1
+ xxd /tmp/tmp.q5iPccsLOn
00000000: 240a                                     $.
+ xxd /tmp/tmp.LCyimJxG8v
00000000: 24                                       $
+ exit 1
+ rm -f /tmp/tmp.q5iPccsLOn /tmp/tmp.LCyimJxG8v


(Note that the script does not have a `#!` line.  Also, you need to have `xxd`
for it to work as intended, but both invocations of this utility are after the
critical part of the code, so you can safely change them to any other hex-dump
program you may happen to have around without breaking the test.  I have also
attached the program I used to generate the test script, which may be easier
to tinker with.)

(The name t-001fa2 refers to the number of padding characters in the script,
before the actual code.)

> I wonder why autoconf-2.69b does not exhibit the issue

I believe this was pure luck.  In your testing, autoconf-2.69b happened not to
generate a script that had \$, inside a here document, at exactly the right
offset.  I don't see any reason why this couldn't have happened with _any_
version of Autoconf.

It's also possible that the bug was recently introduced -- did you patch
IP65-66-246-71.simplesystems.org recently?  I wasn't able to reproduce the bug
with any of /bin/sh, /bin/ksh, or /usr/xpg4/bin/sh on heritage Sun Solaris 10
or 11.

----

Now we know what's wrong, the question is what to do about it.  Of course
OmniOS should be notified.  I looked at https://omniosce.org/ a bit and was
not able to figure out how to report the bug.  (It says that development
happens on Github, and I found a link to what _seems_ to be the repo where
development happens, namely https://github.com/omniosorg/illumos-omnios -- but
that repo has no open issues at all, so I'm guessing that is _not_ the place
to file bug reports.)

It is not feasible to make Autoconf avoid ever writing out backslashes inside
here-documents.  Generation of config.status, in particular, involves using
here-documents to emit shell code, in which backslashes are often necessary.

What we _could_ do is add a test for this sh bug to _AS_DETECT_BETTER_SHELL. 
It would be a little fiddly but not difficult.  I hesitate, though, because of
how sensitive this test would be to unrelated modifications to the shell --
for instance, if someone happens to decide tomorrow that OmniOS sh should read
files in 16kB chunks instead of 8kB chunks, a test that only probed the 8kB
boundary would be invalidated.  How many different offsets do we need to try
before we have confidence that the bug is not present?

cc:ing several other autoconf maintainers for their thoughts.

(file #50563, file #50564)
    _______________________________________________________

Additional Item Attachment:

File name: t-001fa2.sh.gz                 Size:0 KB
    <https://file.savannah.gnu.org/file/t-001fa2.sh.gz?file_id=50563>

File name: test-gen.py                    Size:1 KB
    <https://file.savannah.gnu.org/file/test-gen.py?file_id=50564>



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/support/?110403>

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