Re: gsort problem

[Paul Eggert]

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

> Here's the output of "cc -E tempname.c".

Thanks.  The key lines are here:

      switch (kind)
        {
        case 0 :
          fd = open  (tmpl, 0000002  | 0000400  | 0002000 , 0000400  | 0000200 
);
          break;

        case 1 :
          fd = open  (tmpl, 0000002  | 0000400  | 0002000 , 0000400  | 0000200 
);
          break;

This corresponds to the following source lines in tempname.c:

      switch (kind)
        {
        case __GT_FILE:
          fd = __open (tmpl, O_RDWR | O_CREAT | O_EXCL, S_IRUSR | S_IWUSR);
          break;

        case __GT_BIGFILE:
          fd = __open64 (tmpl, O_RDWR | O_CREAT | O_EXCL, S_IRUSR | S_IWUSR);
          break;

So, both __open and __open64 got expanded into 'open'.  Presumably
that happened because tempname.c says this:

# define __open open
# define __open64 open

In your compilation environment, is plain 'open' a 32-bit open, or a
64-bit one?  I guess I'll assume the former (otherwise there would not
be a problem).  But if that were the case, why do all the other
'open' calls work?

Also, given the above, I don't understand why the fix you reported in
<http://lists.gnu.org/archive/html/bug-coreutils/2006-05/msg00114.html>.
That fix replaced __open with __open64 in tempname.c.  But if __open
and __open64 both expand into plain 'open', then that fix should have
had no effect.  So we have seemingly-contradictory reports here, and
until I understand what's going on here I'd be loath to change the
coreutils source code.

Perhaps you can compare the preprocessor output both before and after
the fix?  "diff" should work.

Also, can you give us the preprocessor output for open-safer.c, so
that we can compare it to the output you already sent?

> fcntl.h:extern int __open64 __((const char *, int, ...));
> fcntl.h:# define open     __open64
> fcntl.h:  { return __open64(a,b,c); }

Under what conditions is the "# define open __open64" line executed?
And what is the context for the { return __open64(a,b,c); } line?

> Oh, and here is the part of config.log regarding mkstemp...

It looks like your host's native mkstemp is indeed busted, so I now
understand why the replacement mkstemp is being compiled.  I wonder
why HP doesn't fix that bug?