any reason to *not* support hex escapes?

[Rob Landley]

On Sunday 02 July 2006 2:23 pm, Bernhard Fischer wrote:
> On Sun, Jul 02, 2006 at 12:34:00PM -0400, Robert P. J. Day wrote:
> >On Sun, 2 Jul 2006, Bernhard Fischer wrote:
> >> On Sun, Jul 02, 2006 at 11:36:12AM -0400, Robert P. J. Day wrote:
> >> >libbb/process_escape_sequence.c:
> >> >--------------------------------
> >> >
> >> >#define WANT_HEX_ESCAPES 1
> >> >...
> >> >#ifdef WANT_HEX_ESCAPES ...
> >> >
> >> >etc etc.
> >> >
> >> >  any reason to not support this feature unconditionally?
> >>
> >> libbb/Config.in ?
> >>
> >> Not sure if these are worth exposing in the menu-thing. Leaving them
> >> in the file so one can hand-tweak if needed is about as good for me
> >> but admittedly limits the number of people who may turn it off if
> >> they know that they will not need it.
> >
> >but is there any obvious reason why someone would explicitly *not*
> >want that feature in the first place?
>
> size / creeping featureitis.

I've had a todo item deal with this for over a year.  It's even in my old todo 
list on http://landley.net/code/todo.txt

sed should use bb_process_escape_sequence()
    Check \? to make sure it doesn't become \\
    Why doesn't this work: [^\"'\n]
      not backslash double quote single quote newline

> >also, given how that routine works, shouldn't the routine return an
> >unsigned char rather than just a plain char?  after all, it's quite
> >possible to be handed an escape sequence of \377, no?
>
> Could very well be, i admit that i didn't look. Please fix this aspect
> if it is not ok as it is.

In busybox, char defaults to unsigned.  We feed -funsigned-char to the 
compiler because otherwise the sign of char varies from platform to platform, 
which sucks.  We default to unsigned so the code is naturally 8 bit clean, 
therefore you'd be fixing something that's not broken.

Rob
-- 
Never bet against the cheap plastic solution.