[Python-bugs-list] [ python-Bugs-232815 ] getname() already in use by OS
noreply@sourceforge.net
noreply@sourceforge.net
Tue, 03 Jul 2001 12:27:16 -0700
Bugs item #232815, was opened at 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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Uwe Zessin (zessin_5)
Assigned to: Fredrik Lundh (effbot)
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 (effbot)
Date: 2001-03-02 00:25
Message:
Logged In: YES
user_id=38376
> I think the Compaq C/ DEC C compilers are quite
> good - I have to blame myself :-(
I did find it a bit hard to believe that the VMS
versions wouldn't be as good as the true64 compilers
(which are as good as they come ;-)
The unsigned complaints are valid, but I'm not sure
how to address them; I don't want the code to break
if someone changes the Py_UCS4 declaration. I'll
leave this one open for now, and ask the python-dev
crowd for advice.
Cheers /F
----------------------------------------------------------------------
Comment By: Uwe Zessin (zessin_5)
Date: 2001-02-27 01:13
Message:
Logged In: YES
user_id=155755
Oops. I've raised a false alarm for UCNHASH.H +
UNICODEOBJECT.C, sorry. The problem was that I
patched UCNHASH.H again.
I think the Compaq C/ DEC C compilers are quite
good - I have to blame myself :-(
However, the compiler's complains for UNICODEDATA.C
and REGEXPR.C is still valid - shold we close this
and open another report for them?
----------------------------------------------------------------------
Comment By: Fredrik Lundh (effbot)
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 (zessin_5)
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