mirror of
https://github.com/topjohnwu/ndk-busybox.git
synced 2024-12-12 14:05:40 +00:00
87e039d016
Indirect calls are more difficult to predict. Unfortunately, on x64 direct call is 5 bytes while indirect "call (reg+ofs)" is 3 bytes: function old new delta i_getch - 82 +82 i_peek - 63 +63 parse_stream 2531 2579 +48 parse_dollar 771 797 +26 parse_redirect 296 321 +25 add_till_closing_bracket 408 420 +12 encode_string 256 265 +9 i_peek_and_eat_bkslash_nl 93 99 +6 add_till_backquote 110 114 +4 parse_and_run_stream 139 141 +2 expand_vars_to_list 1143 1144 +1 static_peek 6 - -6 setup_string_in_str 39 18 -21 setup_file_in_str 40 19 -21 static_get 27 - -27 file_peek 52 - -52 file_get 65 - -65 ------------------------------------------------------------------------------ (add/remove: 2/4 grow/shrink: 9/2 up/down: 278/-192) Total: 86 bytes Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com> |
||
|---|---|---|
| .. | ||
| ash_test | ||
| hush_test | ||
| ash_doc.txt | ||
| ash_ptr_hack.c | ||
| ash.c | ||
| brace.txt | ||
| Config.src | ||
| cttyhack.c | ||
| hush_doc.txt | ||
| hush_leaktool.sh | ||
| hush.c | ||
| Kbuild.src | ||
| match.c | ||
| match.h | ||
| math.c | ||
| math.h | ||
| random.c | ||
| random.h | ||
| README | ||
| README.job | ||
| shell_common.c | ||
| shell_common.h | ||
http://www.opengroup.org/onlinepubs/9699919799/ Open Group Base Specifications Issue 7 http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html Shell & Utilities It says that any of the standard utilities may be implemented as a regular shell built-in. It gives a list of utilities which are usually implemented that way (and some of them can only be implemented as built-ins, like "alias"): alias bg cd command false fc fg getopts jobs kill newgrp pwd read true umask unalias wait http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html Shell Command Language It says that shell must implement special built-ins. Special built-ins differ from regular ones by the fact that variable assignments done on special builtin are *PRESERVED*. That is, VAR=VAL special_builtin; echo $VAR should print VAL. (Another distinction is that an error in special built-in should abort the shell, but this is not such a critical difference, and moreover, at least bash's "set" does not follow this rule, which is even codified in autoconf configure logic now...) List of special builtins: . file : [argument...] break [n] continue [n] eval [argument...] exec [command [argument...]] exit [n] export name[=word]... export -p readonly name[=word]... readonly -p return [n] set [-abCefhmnuvx] [-o option] [argument...] set [+abCefhmnuvx] [+o option] [argument...] set -- [argument...] set -o set +o shift [n] times trap n [condition...] trap [action condition...] unset [-fv] name... In practice, no one uses this obscure feature - none of these builtins gives any special reasons to play such dirty tricks. However. This section also says that *function invocation* should act similar to special built-in. That is, variable assignments done on function invocation should be preserved after function invocation. This is significant: it is not unthinkable to want to run a function with some variables set to special values. But because of the above, it does not work: variable will "leak" out of the function.