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

[SourceForge.net]

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-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