realpath(3) is expensive, and meta mode at least uses it extensively.
We use cached_realpath() to save the result of successful calls to
realpath(3) in a private variable context.
This improves the worst case performance (eg examining libc with
nothing to do) by a factor of 4.
Reviewed by: christos
Both meta_create() and meta_oodate() now share meta_needed()
to indicate if a .meta file is needed.
This allows for deciding that missing .meta file is cause of out-of-date.
The new knob 'missing-meta' controlls this, and is off by default
since the side effect files of generators like yacc will typically need
.NOMETA to avoid problems.
This however makes it much easier for folk to switch back and forth
with meta mode (eg. FreeBSD's normal build can leverage meta mode for
improved reliablility without need to clean).
Also if .MAKE.MODE does not contain 'nofilemon', the knob
'missing-filemon' allows control as to whether missing filemon data
should cause the target to be out-of-date.
Again off by default.
exclude any skell builtin. There are two ways to guarantee exec'ing
a binary, using a path, or using exec. To use a path we would need to
find it first (which certainly could be done.) Using exec here is easier.
ximcp, xlcDef, xlcUTF8Load, xlibi18n, and xomGeneric modules
directly.
also, don't include bsd.lib.mk in the fragment parts for these
modules, but in the module build itself. otherwise, bsd.lib.mk
is included before SRCS is complete and the build strangely
seems to miss parts listed.
tested using the example in the PR.
In libedit, the only way how H_ENTER can fail is memory exhaustion,
too, and of course it is handled gracefully, returning -1 from
history(). So of course, we will continue to handle it gracefully
in add_history() as well, but we are free to decide what to do with
the library state in this case because GNU just dies...
I think the most reasonable course of action is to simply not change
the library state in any way when add_history() fails due to memory
exhaustion, but just return.
If H_ENTER does not fail, we know that the history now contains at
least one entry, so there is no need any longer to check the H_GETSIZE
return value. And we can of course always set current_history_valid.
While testing these changes, i noticed three problems so closely
related that i'd like to fix them in the same diff.
1. libedit has the wrong prototype for add_history().
GNU readline-6.3 defines it as void add_history(const char *).
Of course, that is very stupid - no way to report problems to
the caller! But the whole point of a compatibility mode is
being compatible, so we should ultimately change this.
Of course, changing the prototype of a public symbol requires
a libedit major bump. I don't want to do that casually.
Rather, i will take a note and change the prototype the next
time we need a libedit major bump for more important reasons.
For now, let's just always return 0.
2. While *implicitely* pushing an old entry off the history
increments history_base in GNU readline, testing reveals that
*explicitly* deleting one does not. Again, this is not
documented, but it applies to both remove_history() and
stifle_history(). So delete history_base manipulation
from stifle_history(), which also allows to simplify the
code and delete two automatic variables.
3. GNU readline add_history(NULL) crashes with a segfault.
There is nothing wrong with having a public interface
behave that way. Many standard interfaces do, including
strlen(3). Such crashes can even be useful to catch
buggy application programs.
In libedit/readline.c rev. 1.104, Christos made add_history()
silently ignore this coding error, according to the commit
message to hide a bug in nslookup(1). That change was never
merged to OpenBSD. I strongly disagree with this change.
If nslookup(1) is still broken, that program needs to be
fixed instead. In any case, delete the bogus check; hiding
bugs is dangerous.
Update tsan (not enable, not tested, not compiling)
Merge common infrastructure.
XXX: Perhaps the common code should be made into a separate library?
Or always require asan?
__CTOR_LIST__ and __CTOR_LIST_END__ are logically the same object, but
due to the start marker, the former has to be declared as array of fixed
size. Newer GCC versions take the liberty of exploiting the UB of
accessing global objects past the end to unconditionally load zero
values in that case. Two fixes are possible:
(1) Pruning via inline assembler as done by GCC's own CRT copy.
(2) Pruning via weak references as done for linker sets.
Since the second part is known and required to work anyway, prefer this
approach. In theory, the labels could be replaced completely, except
that GNU as doesn't provide start/end symbols for sections containing
dots.
One part is responsible for generating the SQL query
The other part is responsible for executing the generated query.
While there, also remove a comment which is not valid anymore.
And, don't call the snippet function when doing legacy mode search as we are
not using the full text feature there.
