[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: Closed
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: 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