[PATCH] remove hardcoded selection for HEX ESCAPES(???)

[Rob Landley]

On Wednesday 29 March 2006 11:45 am, Robert P. J. Day wrote:
> On Wed, 29 Mar 2006, Rich Felker wrote:
> > On Wed, Mar 29, 2006 at 11:26:09AM -0500, Robert P. J. Day wrote:
> > >   (if this patch is appropriate, feel free to apply it.  it
> > > removes the hardcoded setting of the macro WANT_HEX_ESCAPES plus
> > > the subsequent conditionals based on it.  it's not clear whether
> > > it makes much sense to have that kind of conditional proprocessing
> > > if it's not a menu configuration selection.  it's also not clear
> > > why you *wouldn't* want hex escapes but if there's a good reason
> > > to keep supporting that, then feel free to toss this patch.)
> >
> > What programs use this file?
>
> a quick recursive grep shows:
>
> coreutils/tr.c
> coreutils/printf.c
> e2fsprogs/fsck.c
> editors/awk.c
> libbb/bb_echo.c
> loginutils/getty.c
> shell/cmdedit.c
> shell/lash.c

I've been meaning to make sed.c use this file, but it turned out not to be 
trivial and thus went on the endless todo list.

On a separate note, It's nice to have gnu extensions annotated somehow so we 
can turn them off for compatibility testing, although it would require a 
large effort to find and mark them all.  (I'd prefer that they be marked 
using the ENABLE mechanism rather than #ifdefs, but that requires them to be 
hooked up to the config menu.)

> > I expect these hex escapes are a GNU extension that's incompatible
> > with SUSv3, in which case it would be nice to be able to disable
> > them along with other GNU extensions.
>
> no argument there.  notice i *didn't* say that this conditional had no
> value.  what i said was that it has little value if it's implemented
> by hardcoding it in the source file.  if it really deserves to be a
> choice, then its selection should be moved to the config menu, that's
> all.

And it needs something like CONFIG_NITPICK.

We've got about another month and a half before we have to start worrying 
about stabilizing the tree for 1.2.  Reorganizing the config menus a bit is 
quite doable, if we can agree on what constitutes and improvement...

> perhaps this feature should be made part of a larger class of
> "non-SUSv3" thingies.  or however that would work.

Well, Glenn already marked a few things obsoleted from susv2...

> rday

Rob
-- 
Never bet against the cheap plastic solution.