3 ms·

> printf '\364%509s\125\252' > main.img It appears that bash `printf` wraps coreutils printf "with ARGUMENTs converted to proper type first," according to the

> printf '\364%509s\125\252' > main.img It appears that bash `printf` wraps coreutils printf "with ARGUMENTs converted to proper type first," according to the manual. I guess that's how the "%509s" specifier is able to work without any args. So how does bash `printf` actually determine the proper arg types? Is coreutils printf implemented with hooks that let wrappers fetch the proper arg types without generating an output string? Or does bash `printf` implement its own separate parser for the format specifier?

kevinoid 8y ago
> It appears that bash `printf` wraps coreutils printf "with ARGUMENTs converted to proper type first," according to the manual. I guess that's how the "%509s" specifier is able to work without any args. Actually, coreutils printf follows POSIX/SUS which states that "Any extra b, c, or s conversion specifiers shall be evaluated as if a null string argument were supplied".[1] So that trick will work for many printf(1) implementations (including both bash and coreutils). Bash printf(1) doesn't have any hooks or wrappers, but it does parse the format string to determine how to convert arguments before calling libc vsnprintf(3). If you are interested in the details, check out how %d/%i is handled in bash[2] and coreutils[3]. 1. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pr... (item 9 under Extended Description) 2. https://git.savannah.gnu.org/cgit/bash.git/tree/builtins/printf.def?h=bash-4.4#n598 https://git.savannah.gnu.org/cgit/bash.git/tree/builtins/pri... 3. https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/printf.c;hb=v8.30#l374 https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;...
- jancsika 8y ago
  Thanks for the links, those are really helpful! Why didn't libc include a printf function that expands a format specifier with a pointer to a byte array (and/or possibly an array of c strings)? That way there would at least be a standard way of handling arbitrary input and erroring out with less risk of buffer overflows and stuff.
sfoley 8y ago
I don’t think bash’s `printf` “wraps” coreutils; pretty sure it just implements the entire call itself.

kevinoid 8y ago

> It appears that bash `printf` wraps coreutils printf "with ARGUMENTs converted to proper type first," according to the manual. I guess that's how the "%509s" specifier is able to work without any args. Actually, coreutils printf follows POSIX/SUS which states that "Any extra b, c, or s conversion specifiers shall be evaluated as if a null string argument were supplied".[1] So that trick will work for many printf(1) implementations (including both bash and coreutils). Bash printf(1) doesn't have any hooks or wrappers, but it does parse the format string to determine how to convert arguments before calling libc vsnprintf(3). If you are interested in the details, check out how %d/%i is handled in bash[2] and coreutils[3]. 1. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pr... (item 9 under Extended Description) 2. https://git.savannah.gnu.org/cgit/bash.git/tree/builtins/printf.def?h=bash-4.4#n598 https://git.savannah.gnu.org/cgit/bash.git/tree/builtins/pri... 3. https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/printf.c;hb=v8.30#l374 https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;...

jancsika 8y ago
Thanks for the links, those are really helpful! Why didn't libc include a printf function that expands a format specifier with a pointer to a byte array (and/or possibly an array of c strings)? That way there would at least be a standard way of handling arbitrary input and erroring out with less risk of buffer overflows and stuff.

sfoley 8y ago

I don’t think bash’s `printf` “wraps” coreutils; pretty sure it just implements the entire call itself.