[Python-bugs-list] [ python-Bugs-524600 ] posixmodule.c fails Tru64 (stat macro)

noreply@sourceforge.net noreply@sourceforge.net
Tue, 02 Apr 2002 09:14:20 -0800


Bugs item #524600, was opened at 2002-03-01 15:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Coleman (mkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: posixmodule.c fails Tru64 (stat macro)

Initial Comment:
posixmodule.c won't compile under Tru64 5.1 (gcc 3.0.3)
because the code assumes that 'stat'/'lstat'/'fstat'
are functions, but under Tru64 5.1 they are macros.



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

Comment By: Patrick Miller (patmiller)
Date: 2002-04-02 09:14

Message:
Logged In: YES 
user_id=30074

>From my reading of the header, we need to

#ifdef STUPID_TRU64_STAT_MACROS
#define __V40_OBJ_COMPAT
#endif
#include "sys/stat.h"

When you do that, the include looks like....
% cpp  -D__V40_OBJ_COMPAT /usr/include/sys/stat.h | fgrep
stat
  struct stat {
  extern int stat ();
  extern int fstat ();
    extern int lstat ();
(some of above lines removed for readability)


Here's the scoop from stat.h

/*
 * Define the function prototypes for stat, fstat and
lstat.  The __(())
 * MACRO is use to control whether ANSI C or K&R style
function prototypes
 * are declared.
 *
 * The normal path will have __EXTERN_PREFIX defined, no
wrapper function
 * MACROs for stat, fstat, or lstat will exist, and the
__F64_XXX__() MACROs
 * will all be no-ops.  This will result in declaring
function prototypes
 * for _F64_stat, _F64_fstat, and _F64_lstat, and all
function calls to
 * stat, fstat, and lstat in the module will be
transparently renamed to the
 * _F64_xxx variant.
 *
 * If a compiler other than DECC is being used then, the
__F64_XXX__()
 * MACROs will perform the function renaming.
 *
 * If the program has created its own wrapper function
MACROs to rename one
 * of the stat, fstat, or lstat functions, then that
function will be
 * declared using the name provided by the program's MACRO. 
The wrapper
 * function prototypes are declared using the new stat
structure (Wrappers
 * that want the old stat structure should be compiled with
 * __V40_OBJ_COMPAT).
 *
 * Finally if either __V40_OBJ_COMPAT is defined, XPG4
standard compliance
 * has been requested, or ISO C or ANSI C standard
compliance has been
 * requested, then the function prototypes will be declared
using the names
 * stat, fstat, and lstat (no function renaming will
occur).  Calls to these
 * functions will return the old stat structure.
 *
 * Again, please do not write programs that directly call
_F64_xxx named
 * fucntions.  Use the standard stat, fstat, and lstat
function names and
 * allow this header file to perform the necessary renaming
as part of the
 * compile.  That way the program will remain portable.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-31 03:31

Message:
Logged In: YES 
user_id=21627

Then this *is* a gcc issue. First, gcc does not implement
the pragma, but should (I just added support for the SunPRO
pragma redefine_extname to gcc for precisely the same
reason: Sun also renames LFS functions). If the #ifdef
really is for DECC, then it is doubtful, though, whether gcc
should define DECC even if it supports the pragma.

It is questionable whose problem this is, but I doubt Compaq
will care much about breakage occurring only with a
third-party compiler. GCC has a strategy for this, so it is
a gcc bug that this strategy is not applied: fixincludes.
GCC produces shadow copies of the system headers to correct
all kinds of problems. It should apply such fixing also to
these headers.

For the specific case, it would probably be sufficient to
change the #define line to

#define stat __F64_stat

Then, taking an address of stat will take the address of
__F64_stat. Better yet, the fixed header files should use
the GCC equivalent of the DECC pragma:

int stat(char*, struct stat*)
  __attribute__((alias("__F64_stat");

Adding this to fixincludes will be a challenge, though; for
Sun, we decided that it is easier to implement the Sun
pragma (especially as it was protected with an #ifdef
__PRAGMA_REDEFINE_EXTNAME, so gcc does not need to claim
being SUNC).

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

Comment By: Mike Coleman (mkc)
Date: 2002-03-30 21:38

Message:
Logged In: YES 
user_id=555

I don't have the code at hand, but it looks something like this:

#ifdef DECC
#pragma something_that_maps_stat_to__F64_stat
#else
#define stat(...) __F64_stat(...)
#endif

I'm quite confident it's not a gcc issue, except in that any
merely standards-compliant compiler would fail here.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-30 00:47

Message:
Logged In: YES 
user_id=21627

So where is the magic that redirects stat to _F64_stat? It
would be ok if there was no stat prototype, under the
'as-if' rule: If that magic behaved as if there was a stat
prototype (i.e. allowing to take the address of stat), then
there would be no problem.

Could it be that this is gcc related? I know that users have
successfully built Python 2.x on Tru64 5.x, probably using
the system compiler. So it might be that gcc has bogus
headers, or is missing a feature that it needs to work
correctly on that machine.

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

Comment By: Mike Coleman (mkc)
Date: 2002-03-29 19:28

Message:
Logged In: YES 
user_id=555

re patmiller: so, that means the Compaq behavior definitely
violates the standard, correct?

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

Comment By: Patrick Miller (patmiller)
Date: 2002-03-29 14:58

Message:
Logged In: YES 
user_id=30074

% cpp /usr/include/sys/stat.h | grep stat
if you look at what is REALLY defined in stat.h in tru64 5.1
you see that there isn't a "extern int stat(...)", just
the bogusified versions of "extern int _F64_stat()"

% cpp /usr/include/sys/stat.h | grep stat
# 1 "/usr/include/sys/stat.h"
# 53 "/usr/include/sys/stat.h"
    unsigned int        __state;
    long        __state;
# 54 "/usr/include/sys/stat.h"
# 55 "/usr/include/sys/stat.h"
  struct stat {
  extern int _F64_stat ();
  extern int _F64_fstat ();
    extern int _F64_lstat ();

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 01:19

Message:
Logged In: YES 
user_id=21627

Section 7.1.4 (use of library functions) of the C standard
(C99) says

#  Each  of  the  following  statements  applies   unless 
# explicitly  stated  otherwise  in  the detailed 
# descriptions that follow: ...
# Any function declared in a header may be additionally
# implemented as a function-like  macro  defined in the
# header, so if a library function is declared explicitly
# when its header is included, one  of the techniques shown
# below can be used to ensure the declaration is not
# affected by  such  a  macro.   Any  macro definition of
# a function can be suppressed locally by enclosing the
# name of the function in parentheses, because the name is
# then not followed by the left parenthesis that indicates
# expansion of a macro function name.  For the same
# syntactic reason, it is permitted to take the address of
# a library function even if it is also defined as a macro.
Posix extends the C standard to additional functions, so the
same rule applies to stat as well (sorry, I don't have the
precise wording for that). Therefore, taking the address of
stat is clearly supported.


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

Comment By: Mike Coleman (mkc)
Date: 2002-03-27 16:02

Message:
Logged In: YES 
user_id=555

The precise error is

Modules/posixmodule.c: In function `posix_stat':
Modules/posixmodule.c:1310: `stat' undeclared (first use in this function)

According to the contents and comments in /usr/include/sys/stat.h,
DEC is playing some #pragma trick in the case that the DEC C
compiler is in use, which maps stat to __F64_stat, and apparently defining only the macros
when a non-DEC compiler is in use.

I don't have a POSIX standard--can you give me a cite I can
take to DEC?


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-03 13:47

Message:
Logged In: YES 
user_id=21627

Can you report how precisely this fails?

The Posix and C standards give the system permission to
define library functions as macros (and Python has no
problem with that) as long as the library *also* defines
them as functions, so you can their address. I doubt that
the Tru64 authors are unaware of this rule, or knowingly
ignore it, so the tru cause must be something else.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470