Re: small incompatibility

[Rici Lake <lua@...>]

On 22-Oct-05, at 12:15 PM, Mike Pall wrote:

> Hi,
>
> Rici Lake wrote:
> > > And a returned string needs to be
> > > processed literally and not with %n escapes. Oh well ...]
> >
> > Well, that's also an option, isn't it?
>
> I think the implementation would get too complicated.

Right, it's three lines longer :)

> And in fact sometimes the %n escapes for the replacement string
> are inconvenient and the string itself needs to be escaped before
> use (or wrapped into a dummy function). I think the inconvenience
> for substitution tables outweighs the benefits. I.e. I'd rather
> not have this for tables.
>
> [This may also be security relevant. Imagine a string received
> from an untrusted source is carelessly put into a substitution
> table. It could cause an exception (i.e. denial of service),
> if it contains an invalid capture index.]

Both of those are existing issues with gsub. Adding the functionality 
to table lookups doesn't affect that. If those are good arguments, then 
%n in replacement strings should just be scrapped (you could also use a 
function instead, after all.)

> Of course the scientific approach is to implement all variants
> and then compare the generated code size plus the size of the
> manual section. Weigh this against the expected usage and the
> amount of time it takes to explain all features to a newbie. :-)

Yes, I agree. That is the best way to decide on new features.