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

[Rob Landley]

On Sunday 04 January 2009 10:05:00 Denys Vlasenko wrote:
> On Sunday 04 January 2009 05:27, Rob Landley wrote:
> > On Saturday 03 January 2009 20:40:48 Denys Vlasenko wrote:
> > > On Saturday 03 January 2009 22:32, 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).

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?

Rob