Re: printf(1), sh(1), POSIX.2 and octal escape sequences

[tlaronde%polynum.com@localhost]

Le Mon, Jul 03, 2023 at 01:36:54PM +0200, ??? a écrit :
> On Mon, Jul 03, 2023 at 06:13:45AM +0000, David Holland wrote:
> > On Fri, Jun 30, 2023 at 05:51:13PM +0200, tlaronde%polynum.com@localhost wrote:
> >  > For this one I will go with the established behavior, but what should I
> >  > do when someone is passing, in octal or in hexa: "\000" ou "\x00"?
> > If you don't support embedded nulls in the strings you're handling
> > (and most things don't), it's an error.
> Or just expand everything unchecked and document that input must
> be a text file before and after expansion, then it's the user's
> fault, especially if they don't know what that means.
> 
> That's how dad did it after all, and that's how other programs in
> the distribution behave.

The String Auxiliary Processor that I have written and is part of inetd
handles strings with length, not relying on '\0' when walking the string
hence allows embedded '\0' (it takes null terminated strings on entry,
but manipulate series of bytes internally and indeed accepts to split
a string with embedded '\0'---I use it in order to make only one
allocation for all the strings of the structure).

So I will accept the embedded escaped nuls even if this will simply
truncate the string afterwards since the remaining of the code
manipulates char *. But this can't, as far as I see, introduce a
security problem. So, as long as the result is acceptable, let it be.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C