[Python-bugs-list] [ python-Bugs-524600 ] posixmodule.c fails Tru64 (stat macro)
noreply@sourceforge.net
noreply@sourceforge.net
Sat, 30 Mar 2002 21:38:23 -0800
Bugs item #524600, was opened at 2002-03-01 17: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: Mike Coleman (mkc)
Date: 2002-03-30 23: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 02: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 21: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 16: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 03: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 18: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 15: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