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

[noreply@sourceforge.net]

Bugs item #524600, was opened at 2002-03-02 00: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: Martin v. Löwis (loewis)
Date: 2002-03-30 09: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-30 04: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 23: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 10: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-28 01: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 22: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