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
