[Python-bugs-list] [ python-Bugs-232815 ] getname() already in use by OS

[nobody]

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: Uwe Zessin
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
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