Hacker News Reader

Comment by jancsika | Hacker News Reader

> 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?

View on HN

> 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/pr... (item 9 under Extended Description)

2. https://git.savannah.gnu.org/cgit/bash.git/tree/builtins/pri...

3. https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;...

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.

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

Reply on news.ycombinator.com