• all writers of exstat ensure the value is in [0; 0xFF]
• all readers of exstat AND it with 0xFF (not strictly needed thus)
• trap_exstat is “safe”, i.e. always either -1 or [0; 0xFF]
several conditions are met as outlined below; for more background, refer to
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=113860
We don’t yet optimise 「% sh -c '{ echo a; sleep 10;}&'; sleep 1; ps T」 so
the FreeBSD® sh approach cannot work for us, but scanning the “sh -c” argu‐
ment for disallowed characters and, if not, setting a flag that enables the
shell to exec the tree when parsed as TCOM *and not c_trap()* was possible.
Disallowed characters are currently C_QUOTE except space, that is:
Tab Newline " # $ & ' ( ) * ; < = > ? [ \ ] ` |
This should catch all cases of magic, variables, subshells, pipelines, etc.
XXX we could track whether tty_fd has already been successfully opened,
XXX the ttystate initialised, and then just never close it unless it is
XXX necessary, then we can keep COLUMNS/LINES accurate in scripts, even
remainging CIDs not listed are either
• false positive (bug in coverity)
• intentional (possibly with lint override coverity doesn't parse)
• VLA (XXX find out how to mix C99 and ANSI VLAs)
• things flagged as possible resource leaks I have no idea about
(no biggie though, and only in error cases I think)
This was actually more evil:
• use a recursive function to display blocks in reverse order,
so that local variable values overwrite global ones
• add array support to typeset -p (from typeset -p -)
• display 'set -A varname' line before setting values, for -p
• if -p got arguments, only display those (from the innermost scope)
Also, the usual amount of code cleanup…
to get rid of the bias introduced by making the hash never zero
… he also pointed out a memory (heap) usage optimisation… which
may impact code size a bit though as I’d need to pass an additional
argument on hashtable function calls… or, forgo the benefit of not
having to pointer-align the key in the structure, which can be as
much as 3/7 octets per item, heap storage… OTOH the saved space is
4/8 octets per not-allocated item, possibly some code (use of an
multiply-add opcode), but the function call overhead/cost would
possibly be quite a bit… I guess I’ll have to measure…
tg