I was recently pointed at a web page on Thomas E. Dickeys site talking about NetBSD curses. It seems initially that the page was intended to be a pointer to some differences between ncurses and NetBSD curses and does appear to start off in this vein but it seems that the author has lost the plot as the document evolved and the tail end of it seems to be devolving into some sort of slanging match. I don't want to go through Mr. Dickey's document point by point, that would be tedious but I would like to pick out some of the things that I believe to be the most egregious. Please note that even though I am a NetBSD developer, the opinions below are my own and not the NetBSD projects.
The first thing that I would like to mention is that the author seems to be incapable of spelling my name correctly. It isn't hard, 4 whole letters but the only time that it is spelt correctly is when the text is copied from a NetBSD commit. If you ever do read this Mr. Dickey, I am not offended, plenty of people struggle with my last name, I am quite used to it.
Before going further, just a bit of background as to how I started working on the NetBSD curses library. I originally was using a commercial x86 port of System V UNIX on my home PC but started looking elsewhere when I found that the SL/IP implementation was bugged. At the time Linux had no networking at all but the BSD source code had just been ported to the PC in a project known as 386BSD. Since this had networking I picked this up and then switched to NetBSD early on. Being used to the SYSV curses I was disappointed to find that there was no real way of handling cursor and function keys in a terminal independent manner as there is in the SYSV curses. I developed and submitted a patch to the NetBSD curses library that added the support for the keypad() function and modified getch() to perform the conversion of key sequences into key symbols. It was on the basis of this patch that I was offered the opportunity to be a NetBSD developer.
When working on NetBSD curses my overall philosophy is to follow The Single UNIX® Specification, Version 2: X/Open Curses, Issue 4 Version 2
(I will refer to this as SUSv2 from now on) where possible, if a behaviour is undefined then I look to ncurses and match the behaviour there if appropriate on the basis that this normally results in less issues for someone porting an application. I add ncurses extensions in response to problem reports (PRs).
Let's now have a look at Mr. Dickey's comments (I am tempted to use the word diatribe but that seems a bit strong...). I won't go over all of them but will pick up the topics that he has mentioned going down his page.
I would like to pick up on the comments about making the window structure opaque. I don't apologise for this, I believe that the fact that WINDOW * was available for applications to poke at is a violation of software layering and just wrong. Later in Mr. Dickey's page he takes NetBSD to task over error checking (more on this later) but by making the contents of WINDOW available for the application there is little use in error checking if the application can just write what they want anyway. It took ncurses until 2007 to opaque WINDOW. Mr. Dickey makes some ominous sounding statements about adding functions to compensate for the opaquing. As far as I am concerned the interface to update a window is specified by SUSv2, if there are extensions that need to be added they will be added as they are needed.
Given I made WINDOW opaque nearly 20 years ago, I have yet to see a PR to indicate that more is needed. The positives of making WINDOW opaque are not only enforcing correct layering of software but it also means that the contents of WINDOW can be modified without requiring a major bump of the library since nothing outside the curses library has access so backward compatibility is maintained.
Making the character string in scanw const just makes sense the function does not need to modify the string so it should be a constant. The NetBSD project does not need to worry about the compiler objecting because the base compiler works with this statement.
Wide curses was a Google Summer of Code project that was done by Ruibiao Qiu. I think that this was a great success and added some very useful functionality to NetBSD curses. It seems that Mr. Dickey is a bit confused by this, in actual fact, he is totally wrong on a number of points:
- The non-spacing characters are not stored as a linked list, they are an array
- The interface for setting non-spacing characters is anything that uses the complex character type (cchar_t)
The non-spacing characters are dynamically added when required, this was my design as I thought that simply having a fixed array for every character cell in the display was a waste of memory, it would be more efficient to only allocate memory as required for the non-spacing characters.
The function specification for ungetch is ambiguous in SUSv2, NetBSD will accept the output from getch on the basis that the input stream has already been processed and it makes no sense to save the last character in what could be a multi-byte sequence.
As for testing of curses, yes, this is mine. I am happy that at least some of our curses functions are being tested to ensure that any changes made don't affect the on-screen output and that if there are changes that they are highlighted and can be analysed for correctness. It is too easy with terminal output to have something that "looks right" but is doing the wrong thing in the background.
Now we get to something I wrote on a mailing list:
Re: curses: create panel from stdscr?
I stand by my comments there. I was referring to my attempt to report what I thought was an issue with the ncurses libmenu implementation. I no longer have the email nor the reply from Mr. Dickey but my clear recollection of the tone and attitude was that I would not be bothered raising issues about ncurses with Mr. Dickey ever again. I wrote the libmenu and libform libraries for NetBSD using the book "Programmer's Guide: Character User Interface (FMLI and ETI)", this is UNIX System Laboratories book so I regard it as definitive for the libraries. I noticed a variance in the ncurses libmenu implementation but as I have stated my efforts of reporting that were not fruitful. Mr. Dickey did reach out to me in late 2017 asking for the email I was referencing, his comment was that my response was vague, actually, my exact words were:
I will try and dig it up. It was a very long time ago. I think it wasAlas I never found the original email but looking at my commits around libmenu I would have sent that email in 1999 some time so I don't think that this is very surprising. At the time of the reply I thought that perhaps there was some interest in actually addressing the issue but the actual fact is that all it was was a fishing expedition to provide more ammunition for an attack on NetBSD curses which is disappointing.
related to some behaviours in libmenu. I will try and dig back through
my mail history but it may take a bit of time.
Getting back to the email quoted above, in the book I have create_panel() is documented as taking a WINDOW as parameter. Though, internally, stdscr is treated as a window the books description of create_panel() does make it clear that WINDOW is expected to be the return from newwin() not just stdscr.
As for missing functions, they will be added as and when the developers have time. A PR may guide us in what is needed first but given that NetBSD is a volunteer project the time that the developers can devote to adding new features can be variable. We are aiming to have something that is useful and not necessarily a clone of ncurses.
Mr. Dickey makes a point about portability. I myself have never been concerned about making NetBSD curses portable, this is not an aim that I have ever had. I would much rather be adding new features and fixing bugs for NetBSD than struggling with the complexities of making the NetBSD curses library portable. If others wish to do this and feed back fixes then they will be considered but in the main, portability is not a focus.
He also turns on some random gcc flags and then berates NetBSD curses for producing extra warnings. It is difficult to determine what flags he has turned on to produce these warnings. The NetBSD build system treats any warnings as errors and the build terminates, the NetBSD curses library builds with the standard NetBSD gcc options without issue. Without knowing what options were uses and what defines were in effect the information that Mr. Dickey has presented is useless. He is welcome to submit a PR using the public interface and it will be looked into.
He then notes the output differences in the wide character implementations. Unfortunately he has not reached out to me (at least) with this information. It would be useful to have the tools to test this issue and rectify it. I will note that he used a rather old version of NetBSD, it would be interesting to see if these issues still exists.
We then have a snide little bit about the number of error returns and error checking. He says "Error-checking in NetBSD curses is seen as a problem by its developers" which is absolutely untrue and uncalled for. He seems to be forgetting at this by that, by his own admission, that NetBSD curses does not have all the functions that ncurses has so there should be less returns of status simply from that. Even if this were not true, if we look at the ratio of ERR/OK returns per number of statements - using the numbers from his page - NetBSD curses has 12987 statements which translates to a ERR/OK return every 25 statements where as ncurses has 24566 statements which translates to a ERR/OK return ever 38 statements. So NetBSD curses actually assigns status codes more often than ncurses. Regardless, I view this metric as specious - simply counting returns is rubbish, look at this:
if ((x > maxx) || (y > maxy))return ERR;
VS:
if (x > maxx)return ERR;
if (y > maxy)return ERR;
Both do the same thing but we get double the ERR returns in the second one. I am not saying this is what is happening but just pointing out the fallacy of counting ERR/OK assignments and trying to draw a conclusion from it without properly analysing the code.
He lambasts NetBSD for commenting out unsupported functions in pycurses, this is just a reflection of the NetBSD curses not having all the functions at the moment. This is a pkgsrc thing and locally applied, pycurses is unique in that it wants all the curses functions so it can provide bindings, since NetBSD curses doesn't have them then the unsupported ones are commented out. It would be ideal if they all existed, hopefully one day they will.
The final thing I would like to pick up on is the comment:
"Without documentation, there is no point in making bug reports."
Which is just a lame excuse, even the lack of documentation is something that can be a bug report. There is a public interface for reporting bugs. Not using it and then complaining on your own website is not helpful to NetBSD but then again, perhaps that is the intention after all.
