Re: [bug-diffutils] bug#16467: Diffutils 3.3 v. VMS (et al.)

[Steven M. Schweda]

From: Paul Eggert <address@hidden>

   Thanks for the prompt response.

> > [...] HAVE_DECL_STRTOLL [...]
>
> I think it's a gnulib bug.  We don't run into compilers lacking
> 'long long' often nowadays, so I'm not surprised the bug is there.

   You need more old-junk computers in your collection.

> I pushed the following patch to gnuliband am cc'ing to bug-gnulib.
> Does this fix the problem for you?

   I assume so.  If HAVE_DECL_STRTOLL is back in the generated config.h
file, then that's good enough for me.  Strictly speaking, it's not every
"VMS's pre-C99 compiler" which lacks "long long", but only the compilers
on VAX.  On Alpha and IA64, the hardware and the compilers are newer,
and have better 64-bit support (including "long long").


> > [...]  On Tru64, I ran into the previously reported "make check" failure
> > caused by the too-modern "export var=value" stuff in that "make" file.
>
> Sorry, I've forgotten which failure that was.  Is it fixed
> in the git master now?  Or do you have a URL for the bug?

      http://lists.gnu.org/archive/html/bug-diffutils/2013-03/msg00014.html


> If you start from a tarball distribution and don't change
> it, 'make check' should not require the use of 'automake'
> (and if it does so I'd like to see how to reproduce the
> bug). [...]

   Probably my fault.  I may have edited too many test/Makefile.* files,
confusing the dependencies, and then failed to clean and start fresh.  I
took another run at it (after getting a newer automake installed), and
had fewer problems.

   There was one test failure on my Tru64 system:

[...]
PASS: test-fcntl
../build-aux/test-driver: 2615 Abort - core dumped
FAIL: test-fdopen
[...]


   dbx says it's at:

   4 main() ["test-fdopen.c":39, 0x120001320]

which seems to be:

      ASSERT (errno == EBADF);

(dbx) p errno
24

which is EMFILE, not the expected EBADF (9).  Replacing the ASSERT
macros with fprintf():

urtx# ./x1
 fdopen( -1) == NULL.  errno = 24: Too many open files.
 fdopen( 99) == NULL.  errno = 9: Bad file number.

   "man fdopen" says that you'll get EBADF for an invalid "filedes"
argument, but apparently a negative value for "filedes" is just too
weird for it.

   I assume that this constitutes a bug in the Tru64 C RTL, but if so,
the probability of getting it fixed these days is approximately nil.
Whether you want to do anything about it (document it, change the ASSERT
condition, supply a better fdopen(), ...) I'll leave up to you.  But you
heard it here first (I assume).

   Most of the VMS adaptations for version 3.3 look very like those I
made for 3.2.  Those went nowhere, but if you're interested in a "diff
-ru" (or something) for 3.3, just let me know.

   Thanks again for the advice.

------------------------------------------------------------------------

   Steven M. Schweda               address@hidden
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547