[Python-bugs-list] [ python-Bugs-232815 ] getname() already in use by OS
nobody
nobody@sourceforge.net
Sun, 25 Feb 2001 09:20:41 -0800
Artifact #232815, was updated on 2001-02-17 05:47
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232815&group_id=5470
Category: Unicode
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Uwe Zessin
Assigned to: Fredrik Lundh
Summary: getname() already in use by OS
Initial Comment:
There is a name-clash on OpenVMS.
modules/unicodedata.c defines a function named 'getname'.
This collides with a function that is defined in OpenVMS's
include file '<unixio.h>'.
Here is an extract from the documentation:
]getname
]
] Returns the file specification associated with a file descriptor.
]
] Format
]
] #include <unixio.h>
]
] char getname (int file_desc , char buffer, . . . );
[...]
] Description
]
] This function places the file specification in the area
] pointed to by buffer and returns that address. The area
] pointed to by buffer should be an array large enough to
] contain a fully qualified file specification (the maximum
] length is 256 characters).
Note: 'getname' is also used in include/ucnhash.h
I guess that 'getname' does also exist on other operating
systems, but might just be included by a different header
file. Can this be changed, please?
----------------------------------------------------------------------
Comment By: Fredrik Lundh
Date: 2001-02-25 09:20
Message:
Logged In: YES
user_id=38376
Umm. If a global function declaration collides with a
struct member, I'd say you're using a seriously broken
compiler. What error message do you get? Are you sure
you've switched on all ANSI compatibility you can get
from your compiler?
----------------------------------------------------------------------
Comment By: Uwe Zessin
Date: 2001-02-25 07:36
Message:
Logged In: YES
user_id=155755
The fix is incomplete. For a clean compile I had to change:
File UNICODEOBJECT.C
1254 if (ucnhash_CAPI->_getcode(start, s-start-1, &chr))
******
File UNICODEOBJECT.C_OLD
1254 if (ucnhash_CAPI->getcode(start, s-start-1, &chr))
and:
File UCNHASH.H
18 int (*_getname)(Py_UCS4 code, char* buffer, int buflen);
******
File UCNHASH.H_OLD
18 int (*getname)(Py_UCS4 code, char* buffer, int buflen);
************
File UCNHASH.H
22 int (*_getcode)(const char* name, int namelen, Py_UCS4*
code);
******
File UCNHASH.H_OLD
22 int (*getcode)(const char* name, int namelen, Py_UCS4*
code);
I have run the code through a newer version of the compiler
and receive the following messages:
UNICODEDATA:
if (code < 0 || code >= 65536)
........^
%CC-I-QUESTCOMPARE, In this statement, the unsigned
expression "code" is being compared with a relational
operator to a constant whose value is not greater than
zero. This might not be what you intended.
at line number 285 in file UNICODEDATA.C
I guess Frederick is handling this anyway, so excuse me
if I just save a little work on opening another bug report
for this one:
REGEXPR
if (ch <= 0 || ch >= RE_NREGS)
............................^
%CC-I-QUESTCOMPARE, In this statement, the unsigned
expression "ch" is being compared with a relational
operator to a constant whose value is not greater
than zero. This might not be what you intended.
at line number 1386 in file REGEXPR.C
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232815&group_id=5470