tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Add curses_version() in curses(3)



Sorry for the top post...
I agree with Roy here, if we add the call we should spit out the
version of the curses lib.  If someone tries to interpret the
contents of the return without consulting the man pages and derives
false information then that is their issue - really the call name
should be indication enough.
The fact this call exists at all in any curses library sort of sucks
but that is another rant entirely :) 

----- Original Message -----
From: "Roy Marples" 
To:"Kamil Rytarowski" , , "NetBSD Discussion List User-Level
Technical" 
Cc:
Sent:Wed, 28 Aug 2019 01:54:54 +0100
Subject:Re: Add curses_version() in curses(3)

 On 27/08/2019 21:14, Kamil Rytarowski wrote:
 > On 27.08.2019 19:29, Roy Marples wrote:
 >> Using Blymns correct email :)
 >>
 >> On 27/08/2019 18:28, Roy Marples wrote:
 >>> On 27/08/2019 17:24, Kamil Rytarowski wrote:
 >>>> Last year, I wrote this patch to add curses_version() for
curses(3).
 >>>>
 >>>> http://netbsd.org/~kamil/patch-00073-curses-version.txt
 >>>>
 >>>> The only purpose of this function is to get better compat with
ncurses
 >>>> software.
 >>>>
 >>>> I needed it originally in qemu. It's sometimes used in the wild.
 >>>>
 >>>> Is it fine to merge it with src/?
 >>>
 >>> Maybe make it return something like
 >>>
 >>> "NetBSD-curses-8.2"
 >>>
 >>> Where 8.2 is taken from the .so version?
 >>>
 >>> Roy
 > 
 > I think that it would be confused with NetBSD release and it could
be
 > meaningless/confusing for downstream users that just pick the code
as is
 > and can pick different major/minor.

 Then I'm against this being added because it adds nothing of value.

 I note that PD curses also supports curses_version() with something 
 similar to my proposal.

 Roy



Home | Main Index | Thread Index | Old Index