[Patches] [ python-Patches-494048 ] removes def of HAVE_WCHAR_H in header

[noreply@sourceforge.net]

Patches item #494048, was opened at 2001-12-16 18:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470

Category: Core (C code)
Group: None
>Status: Open
Resolution: None
Priority: 5
Submitted By: Russ Cox (rsc)
Assigned to: M.-A. Lemburg (lemburg)
Summary: removes def of HAVE_WCHAR_H in header

Initial Comment:
Include/unicodeobject.h #defines HAVE_WCHAR_H if
HAVE_USABLE_WCHAR_T is #defined.  This is bogus:
if the configuration claims to have a usable wchar_t 
without having <wchar.h>, it should be respected.

The patch removes this conditional.



----------------------------------------------------------------------

>Comment By: Russ Cox (rsc)
Date: 2001-12-17 11:07

Message:
Logged In: YES 
user_id=403803

Plan 9 predates the C standard, both of them.  It has a 
completely separate ANSI/POSIX environment that at one 
point was used to compile all of X Windows, but it's for 
POSIX1 and doesn't mix well with the rest of the system.  
(Explaining what that means would take more text than you 
probably care to read.)

I port a lot of software to Plan 9.  If I had a month free 
to spend on such things I'd like to write an updated 
version that adhered to the C99 standard but still mixed 
well with the rest of the system.  Until that happens, I 
have to make do with what I have.

Think about it this way.  The native Windows libraries 
don't adhere to the C standard: when you write native 
Windows programs you #include <windows.h> and use their 
APIs and their type definitions.  Windows also happens to 
provide a set of header files that provides the C99-
mandated interface, but it's a bag on the side.

In the same vein, Plan 9 provides its own library interface 
for native programs.  Unlike Windows, Plan 9 doesn't have 
an up-to-date bag on the side for C99 (or even the C89 
addons like wide characters).  But it's close enough that I 
can port large software packages like Python, Ghostscript, 
and CVS without much trouble.

I agree that it would be better if there was a standard C 
interface that could be used.  It just isn't there.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-17 11:05

Message:
Logged In: YES 
user_id=6380

I don't understand how asking robust portable 3rd party
software to change is "doing things better".

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-17 10:59

Message:
Logged In: YES 
user_id=31435

Guido, I expect it's because the C standard sucks <wink> -- 
Plan 9 seems more of a researchy thing, looking into how 
things could have been done better.  An interesting read 
about their C mutant:

http://www.lysator.liu.se/c/plan9c.html

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-17 10:37

Message:
Logged In: YES 
user_id=6380

Sigh. Why does Plan 9 want to fight the C standard?

----------------------------------------------------------------------

Comment By: Russ Cox (rsc)
Date: 2001-12-17 10:29

Message:
Logged In: YES 
user_id=403803

Plan 9 has a single include file <libc.h> that provides
everything you'd think of as the C library, except stdio.
Also, Plan 9 calls the Unicode character type Rune instead 
of wchar_t, so I typedefed one in Plan 9's pyconfig.h and
set HAVE_USABLE_WCHAR_T (Runes are 16-bit unsigned 
integers) but not HAVE_WCHAR_H.  Rereading the various 
things that are excluded if you don't HAVE_WCHAR_H, it's 
clear that in my case I should just create an empty wchar.h 
and defined HAVE_WCHAR_H.  So I'd be happy to drop this.

However, I do think that the code is at least misleading.
If configure is doing a bad job then, as Tim suggests, 
configure should be fixed.

Perhaps a better replacement would be:

#if defined(HAVE_USABLE_WCHAR_T) && !defined(HAVE_WCHAR_H)
#error "HAVE_USABLE_WCHAR_T requires HAVE_WCHAR_H."
#endif

Sorry for the hassle.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-17 09:27

Message:
Logged In: YES 
user_id=31435

wchar.h and wctype.h were added to the C89 std by Amendment 
1, published in 1995.  Since they've been standardized for 
more than 6 years, I don't think we should try to cater to 
non-standard implementations.

So I'd rather see a config test for HAVE_USABLE_WCHAR_T 
check that checks for the presence of wchar.h too.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-12-17 01:53

Message:
Logged In: YES 
user_id=38388

Well, if wchar_t is considered usable, then the header file defining it will have to present as well. I don't see why 
HAVE_USABLE_WCHAR_T should be defined without having the wchar.h header files available.

Russ, perhaps you could explain why you feel this patch is necessary ?!

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-16 18:49

Message:
Logged In: YES 
user_id=6380

Assigned to MAL -- Marc-Andre, do you recall why this was
done this way? Do you think the patch is safe? (Not to be
applied in 2.2, but considering for 2.3 or even 2.2.1.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494048&group_id=5470