Re: Interning strings considered harmful (somewhat)

[David Kastrup <dak@...>]

"Matthew P. Del Buono" <delbu9c1@my.erau.edu> writes:

> Florian Weimer wrote:
>> * Roberto Ierusalimschy:
>>> Excluding malware, I do not think this situation happens enough to
>>> justify any worry.
>> 
>> I know the argument: anybody who wants to take out your web server can
>> just flood it with 5 Gbps of traffic (or more if necessary).
>> 
>
> I think you already have an issue if you're being flooded like that anyway.
>
>> Would an uninterned string type introduce too many additional code
>> paths in the VM?
>
> Why make a change to the VM? Why can't you just do it yourself? The
> only logical way to add an uninterned string type would be to enforce
> that uninterned strings and interned strings are considered two
> distinct types. Accordingly, uninterned strings are never equal to
> interned strings, even if their contents are equal.
>
> Following the above logic, we can implement uninterned strings
> trivially as userdata. An __eq metamethod can be provided which passes
> off execution to strcmp (additional work may be neccessary to handle
> strings with zeros). We would use this userdata only for "insecure"
> strings, that is, strings that the remote user can influence. If we
> need to test between interned strings and our userdata, the userdata
> could provide a method through __index that allows for comparison
> against a string.
>
> Don't change what isn't broken. Userdata were made for special
> situations and types just like this.

One can't use Lua's string operations (in particular pattern matching)
on userdata, and there is no actual necessity to intern them for most
applications (excepting indexing or fast equality tests).

-- 
David Kastrup