[Patches] [ python-Patches-806800 ] NetBSD py_curses.h fix

Wed Oct 22 10:03:58 EDT 2003

Patches item #806800, was opened at 2003-09-15 22:47
Message generated for change (Comment added) made by marc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=806800&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marc Recht (marc)
Assigned to: Nobody/Anonymous (nobody)
Summary: NetBSD py_curses.h fix

Initial Comment:
On NetBSD, [n]curses.h and stdlib.h/wchar.h use
different guards
against multiple definition of wchar_t and wint_t.

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

>Comment By: Marc Recht (marc)
Date: 2003-10-22 16:03

Message:
Logged In: YES 
user_id=205

ATM i'm doing some tests with a patch that disables 
_XOPEN_SOURCE_EXTENDEND on NetBSD 1.5/1.5.* NetBSD 1.6/1.6.* 
and some older versions of -current. For newer versions of -curernt the 
definition of _NETBSD_SOURCE 'fixes' the problems introduced by the posix 
macros. 

The curses problem is more a generic problem. wchar_t / wint_t are defined as 
"integer types" by POSIX
see:
http://www.opengroup.org/onlinepubs/007904975/basedefs/stddef.h.html
http://www.opengroup.org/onlinepubs/007904975/basedefs/wchar.h.html

On NetBSD wchar_t is an 'int' and ncurses defines it to 'unsigned long'. Thus 
the declaration clash. And this can happen on any os that defines wchar_t and 
uses ncurses for python. Because of that i think the test should be something 
like:
if defined(_XOPEN_SOURCE_EXTENDED) && defined(HAS_WCHAR_T)
&& defined(NCURSES_VERSION)

(And maybe a similar with HAS_WINT_Tif we can't assume that the os declares 
wint_t if it declares wchar_t.)

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-10-22 05:57

Message:
Logged In: YES 
user_id=29957

Note that the configure script in the trunk and 2.3 branch
already has a workaround for this - it doesn't define the
_XOPEN_SOURCE_EXTENDED macro for FreeBSD and Darwin. If the
same fix is needed for NetBSD, could you supply a patch for
configure.in?

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

Comment By: Marc Recht (marc)
Date: 2003-10-22 00:44

Message:
Logged In: YES 
user_id=205

NetBSD ;-)
But, you're right. It's the problem of the ncurses package and not NetBSD's 
(nor FreeBSD's since it has a similar fix).
It has also already been fixed in the dev. version of ncurses. I'm going to 
backport the fix for the NetBSD pkgsrc version of ncurses, but the problem 
remains for people who are using (or try to use) stock python and ncurses 
sources. I still don't see a version test here. Digging in CVS shows that wchar_t 
has been around for ages now (and it's going to stay).
A solution could be to test for the existence of wchar_t in configure and change 
the test to something like: 
if defined(_XOPEN_SOURCE_EXTENDED) && defined(HAS_WCHAR_T) 
&& defined(NCURSES_VERSION)
#ifndef _WCHAR_T
#define _WCHAR_T
[...]

And thus making it OS independent.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-10-18 12:25

Message:
Logged In: YES 
user_id=21627

Ok, then I still maintain that this is a bug in FreeBSD -
namely, in the package. There should then still be a test
for versions, so that we know when we can take the
work-around out. Otherwise, the work-around will stay in
forever, as we have no means of knowing whether it is still
needed. That would be bad.

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

Comment By: Marc Recht (marc)
Date: 2003-09-23 19:31

Message:
Logged In: YES 
user_id=205

Just one note that might clarify things a bit more...
ncurses is installed with the pkgsrc system (like FreeBSD's
ports). It doesn't get installed with the base system nor is
it in one of the system directories. (It's in /usr/pkg.)
NetBSD has a curses implementation, but it has not (yet) all
the features Python needs. Because of that we use GNU
ncurses (atm 5.3).

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

Comment By: Marc Recht (marc)
Date: 2003-09-23 16:58

Message:
Logged In: YES 
user_id=205

Oh. I think we're talking at cross-purposes. The _system_
curses isn't used, it's GNU ncurses. And ncurses and char.h
clash if _XOPEN_SOURCE_EXTENDED is defined.
Naturally the system curses and wchar.h could be included
together.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-09-19 00:45

Message:
Logged In: YES 
user_id=21627

Is it the case that curses.h and wchar.h cannot be
simultaneously be included if a certain supported #define is
given? If so, it is clearly a bug in the header files - it
should not be possible to get conflicting declarations by
just including system headers.

Even if it applies to all released versions of the system, I
still need an explicit list of what these versions are, and
I need a compile-time failure if a version is encountered
that isn't listed. That the next release is only a year away
is a good thing - maybe they can fix the bug until then.
They won't, of course, fix the bug if nobody tells them
there is a bug...

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

Comment By: Marc Recht (marc)
Date: 2003-09-18 23:51

Message:
Logged In: YES 
user_id=205

Hmm. I won't consider it a bug in NetBSD. Just a clash of
declarations.. ;-)
The attached patch is needed for 1.6.x and -current (which
will be released not sooner than next year). I'm not sure
about 1.5, but I'd bet it's the same.
So, there's just no restriction possible. It's simply - all
- (if _XOPEN_SOURCE_EXTENDED is defined).

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-09-18 20:33

Message:
Logged In: YES 
user_id=21627

That is a work around a NetBSD bug, right? If so, there
should be some procedure to retest presence of the bug in
new NetBSD releases, and record the versions for which the
bug has been found to be present. Then, when the newest
release with the bug is not supported in Python anymore, the
code can be removed (which might well be 10 years from now).

If possible, a code fragment like

#if (NetBSD_major == 3) or (NetBSD_major==4)
// bug present, add work-around
#else
#error Please check whether the bug is still present
#endif

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

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