Issue 524600: posixmodule.c fails Tru64 (stat macro) (original) (raw)

Issue524600

Created on 2002-03-01 23:44 by mkc, last changed 2022-04-10 16:05 by admin. This issue is now closed.

Messages (12)
msg9471 - (view)	Author: Mike Coleman (mkc)	Date: 2002-03-01 23:44
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.
msg9472 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2002-03-03 21:47
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.
msg9473 - (view)	Author: Mike Coleman (mkc)	Date: 2002-03-28 00:02
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?
msg9474 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2002-03-29 09:19
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.
msg9475 - (view)	Author: Patrick Miller (patmiller)	Date: 2002-03-29 22:58
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 ();
msg9476 - (view)	Author: Mike Coleman (mkc)	Date: 2002-03-30 03:28
Logged In: YES user_id=555 re patmiller: so, that means the Compaq behavior definitely violates the standard, correct?
msg9477 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2002-03-30 08:47
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.
msg9478 - (view)	Author: Mike Coleman (mkc)	Date: 2002-03-31 05:38
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.
msg9479 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2002-03-31 11:31
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).
msg9480 - (view)	Author: Patrick Miller (patmiller)	Date: 2002-04-02 17:14
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.
msg9481 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2002-04-02 17:30
Logged In: YES user_id=21627 So what is the difference between the old and the new stat structure? Defining __V40_OBJ_COMPAT seems wrong to me; I assume you want to use the new stat structure, and you do want to call the F64 functions. If the compiler does not support that scenario, it's a compiler bug. patmiller's comment offers a work-around, though: putting __V40_OBJ_COMPAT into CFLAGS (and probably OPT as well) should allow compilation to succeed. Closing as 'won't fix'.
msg9482 - (view)	Author: Mike Coleman (mkc)	Date: 2002-04-03 01:33
Logged In: YES user_id=555 It sounds like a gcc guy is working on a fix for this, probably for 3.1. (It's an implementation of that pragma plus a fixincludes change.) This fix should work around the underlying Compaq bug.