Fix warnings found by NetBSD #2870
Conversation
…l for GitHub to work Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…AX+1 to allow for ending NUL char [networkupstools#823] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
… to unsigned char when using as array subscript [networkupstools#823] This may be an implicit array, such as tolower() implementation as a ctype(3) macro rather than function. Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…profile edits Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
|
More or less read the code and looks good. A nit is that the unigned char is necessary not because it might be an array but because POSIX says it's UB to pass a value that is other than EOF and those that are legal for unsigned char. (It's implicit that implementations may optimize and are free to produce UB when the spec says UB.) Not a big deal, but so many people fail to understand the spec/UB issue. |
|
Why is NetBSD's shell Usual alphanumeric sort: decent With numeric argument: broken - pure numeric strings are sorted as numbers go (e.g. 55 after 8), but other strings just dumped in same order as they were, at start of output (numbers after letters ignored and not sorted either):
|
|
✅ Build nut 2.8.2.2931-master completed (commit 22641649e2 by @jimklimov) |
You didn't show that it was broken, just not what you expected. As I read POSIX https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sort.html It's quite clear "restrict to initial numeric" and therefore all the non-numeric are empty/0 and thus can be sorted arbitrarily while complying with POSIX. |
|
I'd invoke principle of least surprise: output of a I agree pedantically it is not incorrect, e.g. pure-numeric sort is not defined for non-numeric tokens, so any order of those including original or random is not-wrong. But it is also not a useful result. Like in those fun tales about mathematicians' replies. Do you know OTOH a POSIX CLI option combo to sort alphanumerically and number-aware for punctuation/whitespace surrounded numbers with leading parts of the strings being equal, at the same time? |
I see your point, but you're basically arguing that the spec should have said more than it does, and surely they argued about it (that's what POSIX committees do) and it says what it says. The other side of the coin is that it takes CPU time to do things that aren't required, and the view that there is merit in the least-cost conforming output. You can use -k, and specify multiple keys; the later one only matters if the first compare equal. This sorts the non-numeric keys, and they end up as a group sorted as 0. Should get the same answer on all complying systems. "punctuation" is hard as numeric is defined to handle -, radix, thousands separator. Unfortunately sort's design expects "fields" with a separator (space, :, |) and within each field to be sorted either charset-wise or numeric, more or less. |
|
Valid points. And your example is intriguing. I figured expression of complex desires would go through key specs (how else), but did not realize you can specify the same key twice - always did them for different numbers... "Live for a century, learn for a century!" indeed :) |
…numeric+alpha sort [networkupstools#2870] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
|
I had never thought about specifying a key twice, but the spec clearly doesn't say you can't, and sure enough it worked. |
…numeric+alpha sort [networkupstools#2870] Thanks to Greg Troxel @gdt for the hint and fruitful discussion. Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…c and its pkgin tool Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
"make" package is absent, `/usr/bin/make` appears from something I could not track down; however there is a separate but similar "bmake" as `/usr/pkg/bin/bmake` that can be installed. Probably a difference of system vs. userland tooling variants. Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…endencies for NUT-Monitor Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
|
One more issue cropped up, similar to #2782 seen in OmniOS builds: the pkgsrc libraries are located under However their As a result, during NUT build the toolkits see them (thanks to Or, to be fair, SOME libraries do report these bits and do get found "out of the box": In OmniOS this was accepted as a distro error, maybe was fixed since. As a hot-fix, hacking |
…workupstools#2870] Just renamed the private enum values. Earlier code complained with NetBSD clang-18: mge-xml.c:76:2: error: identifier '_UNEXPECTED' is reserved because it starts with '_' followed by a capital letter [-Werror,-Wreserved-identifier] 76 | _UNEXPECTED, | ^ mge-xml.c:77:2: error: identifier '_PARSEERROR' is reserved because it starts with '_' followed by a capital letter [-Werror,-Wreserved-identifier] 77 | _PARSEERROR, | ^ 2 errors generated. Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…etBSD pkgsrc dependencies to be found out of the box Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…r now [networkupstools#2870] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…etBSD libltdl dependency to be found out of the box Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…elp NUT at the moment Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
|
Despite having the packages installed, NUT failed to make use of:
|
|
❌ Build nut 2.8.2.2933-master failed (commit 1766d9a184 by @jimklimov) |
…t also net-snmp, packages need CHECK_OSABI=no in /etc/pkg_install.conf [networkupstools#2870] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
|
I agree that a pkg-config file with -L and not -R is a bug and should be patched in pkgsrc (and probably fixed upstream, but many upstreams take an "of course you are using Linux and installing in /usr" attitude). As for things not having pkg-config, it is historically normal to add CPPFLAGS/LDFLAGS to a program build to tell it where dependencies are. Then, various programs grew Overall, I would say that when building a program where dependencies are in some prefix, one has to pass CPPFLAGS/LDFLAGS, and it's a special case on most GNU/Linux that everything is in /usr. When pkgsrc builds programs, it does pass CPPFLAGS/LDFLAGS. This is almost certainly why the failure to have -R in openssl has not been noticed and fixed. |
|
✅ Build nut 2.8.2.2934-master completed (commit 4f672930b9 by @jimklimov) |
|
Some hiccup in tests against Mozilla NSS - does not seem to honour the UPDATE: Must be going blind. It is not a problem of linker UPDATE2: Or maybe it is, the crypto libs are wanted by the Oddly, e.g. |
Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
|
Will separate spellcheck revision commits as not NetBSD-specific. => #2871 |
|
So indeed, the linking calls go like this:
but-but-but, the recipe is there to add UPDATE: Maybe caught the difference, checking |
…BSSL_LDFLAGS_RPATH when linking both libnutscan.la library and nut-scanner program [networkupstools#2870] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…E_UNINITIALIZED(_BESIDEFUNC) Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…A_GCC_DIAGNOSTIC_IGNORED_MAYBE_UNINITIALIZED Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
… setters from BoolInt instances Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…r too Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…s, if any - consider not-set Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
Also test added NUT CI farm worker with NetBSD
CC @gdt