The busybox "printf" command is always 32 bit even when the shell isn't.

[Denys Vlasenko]

On Sunday 04 January 2009 20:11, Rob Landley wrote:
> > > > > $ printf %x 2251797561885434; echo
> > > > > 7ffff79c842fa
> > > > > $ ./busybox printf %x 2251797561885434; echo
> > > > > 79c842fa
> > > > >
> > > > > I need 64 bit math to convert timeconst.pl to timeconst.sh in the
> > > > > Linux kernel build...
> > > >
> > > > By your command
> > >
> > > Thanks, and I'm happy to have this patch now to help get the perl removal
> > > stuff into the kernel, but going forward I think there should probably be
> > > a big config switch, "use 64 bit math on 32 bit platforms".
> > >
> > > Generally if you want 64 bit math, you probably want it everywhere, but
> > > 32 bit systems will be with us in the embedded world for a while yet
> > > (especially arm and mips and such), and doing unnecessary 64 bit math
> > > there is especially painful.
> > >
> > > Also, what's the deal with ash "built in printf"?  Does this relate to
> > > nofork, or is it a separate implementation, or...?
> >
> > Shells have "builtins". Which are sort of NOFORK, but are enabled
> > independently of NOFORK. The rationale is that even if you do not
> > use NOEXEC and NOFORK _applets_ (which is understandable,
> > they are not as stable as I would like),
> > you sure want "echo", "test" etc in shells to not be slow as hell.
> 
> The only reason nofork applets would be unstable is because the applet in 
> question doesn't clean up after itself or uses the wrong error handling 
> functions (exiting on error isn't nice if it kills your shell).

Or shell user running "rm -rfi" and pressing Ctrl-Z at rm's prompt.

Think what shell needs to do to properly create a child, and clean up
open fds (opened by rm by virtue of doing recursive directory removal),
rm's allocaled memory etc etc etc. This is not simple.

Perhaps we can declare that NOFORKs are not background'able from shell,
and accept the fact that this either severely restricts the set of applets
that can be NOFORKs (for example, cat can't be: "cat 14gig_file >/dev/disk"
takes a long time), or creates an unexpected behavior for them
when they are used from shell.

What do you think about it?

> But if you _have_ a printf implementation that you know is safe to use in the 
> shell, why would you have a second applet implementation?  And if they are the 
> same implementation, what's the second config entry for?

They are the same implementation. What is "the second config entry"?
I see only one entry which controls whether printf is a builtin or not.
--
vda