Re: gsort problem

[Paul Eggert]

"Simon Wing-Tang" <address@hidden> writes:

> I've just completed a test after altering one part of the source
> code for tempname.c ( lib/tempname.c ) as follows....
> Original: ...
>    271          case __GT_FILE:
>    272            fd = __open (tmpl, O_RDWR | O_CREAT | O_EXCL, S_IRUSR | 
> S_IWUSR);
> ...
> Modified: ...
>    271          case __GT_FILE:
>    272            fd = __open64 (tmpl, O_RDWR | O_CREAT | O_EXCL, S_IRUSR | 
> S_IWUSR);

> After a recompile the sort worked

Thanks for the bug report and the detailed investigation.  However,
I don't understand why your fix worked, because the lines that you
mentioned are preceded by these lines in tempname.c:

   75  # define __open open
   76  # define __open64 open

so it should make no difference on your platform whether __open or
__open64 is used.

Since I don't know why your change worked, I'm not convinced that we
actually understand the bug yet.  It could well be that the bug will
come up again in some other 'sort' run.

Can you please investigate why the #define's did not work as one would
expect?  For example, what is the preprocessor output (cc -E) for
tempname.c?  Are the symbols __open and/or __open64 defined in HP-UX's
headers?

Also, can you please investigate why coreutils is compiling tempname.c
at all?  Coreutils does so only if it concludes that the system
mkstemp has stupid limitations (e.g., mkstemp cannot create more than
26 files from a given template).  HP-UX 10.20 had such a problem, but
is this limitation still present in HP-UX 11.11i?  If not, we need to
fix m4/mkstemp.m4 so that it no longer builds a substitute mkstemp on
your platform.  You can look at config.log to see why the build
decided that mkstemp was broken.

Thanks.