mark obsolete usage of fold

Rob Landley rob at
Sun Dec 11 06:30:11 UTC 2005

On Saturday 10 December 2005 16:53, Glenn L. McGrath wrote:
> Attached is a patch sets a feature to allow 'fold -40' type arguments
> to fail, this behaviour is obsolete even in susv2.
> Im sure some scripts (e.g. configure) are still using it, so its
> usefull to support it.
> The patch doesnt change default behaviour. Its really just to start to
> organise things so we can one day have a global setting to choose what
> posix standard to compile to.

1) If you're going to do this kind of thing, could you please have a global 
argument to disable nonstandard extensions?  (I'm trying to keep the amount 
of configuration people have to do down to a dull roar.  Getting buried in 
options doesn't help.  I'm thinking of adding things like CONFIG_NEEDS_PROC 
and CONFIG_LONG_OPTIONS to 1.2, for example.)

2) I'm trying to get 1.1 out by new year's.  Could this kind of change please 
wait until January?  (See big long bug list posted a couple days ago.)

3) I really think we should pick one standard we care about, and try to 
implement all of.  (Right now it's that Open Group thing that's on the web, 
which is roughly susv3.)  Trying to distinguish between susv2 and susv3 is 
just going to drive us _crazy_.

4) We now have if(ENABLE_BLAH) rather than #ifdef CONFIG_BLAH.  In 1.2 I'm 
hoping to do a big switchover and cleanup (after documenting it and figuring 
out what compiler versions competently handle dead code elimination).

5) My worries about standards compliance currently are about filling out the 
test suite and making sure we implement everything we need to.  What's the 
advantage of #ifdefing _out_ extensions that are still used?  (It's not 
complexity savings if the code is still there.  What are the space savings?  
When we have tiny little changes that save tiny little amounts of space, I 
like to group them together under bigger config options.  I'm not _against_ 
saving 5 bytes here and 5 bytes there, but someday I'd like to have somehting 
like a CONFIG_NITPICK to hide all config options that save less than 100 
bytes each.  :)

6) I can see the advantage of disabling things like gnu extensions when people 
want to use our code to test standards compliance, but right now we don't 
implement anything close to the whole standard yet so do we want to start 
worrying about that now?

> Its been a long time since i committed anything, i expect to be more
> active in the future...

Welcome back. :)

> Glenn

Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.

More information about the busybox mailing list