These were only used on PDP-11 for two programs we don't ship,
and have been obsolete since the VAX days.
xstr never worked in the build.sh cross-build environment (22 years), or
parallel make environment (nearly 28 years), didn't work in the orignal 386bsd
import, and has never been needed in NetBSD as we don't have the older BSD
programs (pascal, pre-nvi ex) that needed mkstr/xstr on PDP-11.
PR toolchain/35964
suggested fixes from Tom Lane. I played it safe and went with (my
variation of) the minimal fix.
port-hppa/56118: sporadic app crashes in HPPA -current
Patch from RVP on NetBSD-Users, with an additional comment tweak by me.
Summary from RVP:
1. Ignore SIGPIPE so that we're not killed in the middle of some
DB operation by a botched $PAGER:
$ env PAGER=/non-existent apropos -p ...
2. Return proper exit status in case of write errors:
$ apropos ... >/dev/full || echo fail
-s is not for compatibility only, because section names can be
anything. E.g. we have 3lua and 9lua in base. We have rudiments of
3f (for FORTRAN libs). Some packages in pkgsrc also use suffixed 1
and 3 sections.
There's no point initializing database state if we're then going to
fail to locate any man page sources. Make all the initial state checks
contiguous for simplicity and readability. Also, free the variable
"command" on the error path, and correct the error message.
Since 2021-01-31, lint no longer requires a CONSTCOND comment in a
do-while-0 statement since this is a common code pattern, especially in
statement-like macros.
sed -i -E 's,} while \(/\* ?CONSTCOND ?\*/ ?0\),} while (0),' */*.[ch]
at least a few pkgsrc packages avoid base sqlite because it fails
this check, and it's probably a surprising performance penalty for
unsuspecting users
This is a driver for a "nonsense machine" made by the art group Maywa-Denki
in 2008. It was disabled by default.
Unfortunately even so it draws development attention (flaws found in the
code, MP-ification needs) and it is best not to continue to maintain this
driver.
Proposed without objections on tech-kern.
The previous commit fixed the problem of allowing apropos to not crash and
produce output even if the database is missing values for certain mandatory
fields, such as name, section etc. Normally we don't expect those values
to be missing in the database but in case of parsing errors it can happen.
However, the machine architecture is an optional field since not all man pages
are hardware specific so that should be allowed to be set to NULL if not
present in the database.
In revision 1.6 of whatis.c the query was modified to return matches for names found
in MLINKS of the man pages as well. However it was slow. The reason probably being that it
required a join. But more importantly the where condition on an FTS virtual table column
is very slow. To avoid the join and the expensive where condition on the virtual table,
add the name_desc column to the mandb_links table as well. This improves the performance
of whatis(1) to the original level at the expense of slight data duplication.
Bump the schema to force database rebuild to take account for the new column addition
This was causing memory corruption thus making apropos(1) fail in some cases.
Specifically following options were broken and should be fixed with this commit:
-n option was causing a core dump
apropos was giving warning when using -l and any of the section numbers as options
as reported by paulg on current-users.
mparse_alloc() altered - update the call here to compensate.
This fixes the build (of makemandb), but I am not sure that
the changed version is what is desired - someone who knows
something about all of this should validate ... I just copied
the invocation from mandoc's demandoc.c (which seems likely
to be at least a similar kind of usage).
If we want to add or remove arguments from the callback functions, it requires
changing the callback interface all over the place. By letting the callback simply
expect a single struct argument, it would clean things up a bit.
ok christos
alignment issues on some platforms (e.g. Sparc64)
So, Use a temporary variable to avoid the cast.
Thanks to Martin@ for noticing the issue and also suggesting the issue.
Fixes PR bin/52678
Using the custom tokenizer means one cannot interactively query the database
through the SQLite shell, thus thwarting the purpose of the debug build option.
Thanks to leot@ for reporting it.
(While there change the debug macro from DEBUG to APROPOS_DEBUG)
Which keywords should not be stemmed is specified in the nostem.txt file.
(Right now I have taken all the man page names, split them if they had
underscores, removed common English words and converted everything to
lowercase.)
The tokenizer itself is based on the Porter stemming tokenizer shipped with
Sqlite. The code in custom_apropos_tokenizer.c is copy of that code with
some modifications to prevent stemming keywords specified in nostem.txt.
Additionally, it now uses underscore `_' also as a token delimiter. Therefore,
now it's possible to do query for `lwp' and all `_lwp_*' man page names
will be matched. Or the query can be `unconst' and `__UNCONST' will be matched.
This was not possible earlier, because underscore was not a delimiter and therefore
the index would have __UNCONST as a key rather than UNCONST.
The tokenizer needs fts3_tokenizer.h file, which is not shipped with the
amalgamation build of Sqlite, therefore it needs to be added here (unless
we decide there is a better place for it).
To enforce using the new tokenizer, a schema version bump is needed
Since the tokenization is done both at the indexing time (via makemandb) and
also while query time (via apropos or whatis), it will be needed to bump
the schema version everytime nostem.txt is modified. Otherwise the
index will consist of old tokens and desired changes will not be seen with
apropos.
This should also fix the issue reported in PR bin/46255. Similar suggestion was
also made on tech-userlevel@ recently:
<http://mail-index.netbsd.org/tech-userlevel/2017/06/08/msg010620.html>
Thanks to christos@ for multiple rounds of reviews of the tokenizer code.
Originally, MKCRYPTO was introduced because the United States
classified cryptography as a munition and restricted its export. The
export controls were substantially relaxed fifteen years ago, and are
essentially irrelevant for software with published source code.
In the intervening time, nobody bothered to remove the option after
its motivation -- the US export restriction -- was eliminated. I'm
not aware of any other operating system that has a similar option; I
expect it is mainly out of apathy for churn that we still have it.
Today, cryptography is an essential part of modern computing -- you
can't use the internet responsibly without cryptography.
The position of the TNF board of directors is that TNF makes no
representation that MKCRYPTO=no satisfies any country's cryptography
regulations.
My personal position is that the availability of cryptography is a
basic human right; that any local laws restricting it to a privileged
few are fundamentally immoral; and that it is wrong for developers to
spend effort crippling cryptography to work around such laws.
As proposed on tech-crypto, tech-security, and tech-userlevel to no
objections:
https://mail-index.netbsd.org/tech-crypto/2017/05/06/msg000719.htmlhttps://mail-index.netbsd.org/tech-security/2017/05/06/msg000928.htmlhttps://mail-index.netbsd.org/tech-userlevel/2017/05/06/msg010547.html
P.S. Reviewing all the uses of MKCRYPTO in src revealed a lot of
*bad* crypto that was conditional on it, e.g. DES in telnet... That
should probably be removed too, but on the grounds that it is bad,
not on the grounds that it is (nominally) crypto.
lukem