[m-rev.] for review: avoid "poison null" security vulnerabilities

[Ralph Becket]

Simon Taylor, Wednesday, 14 March 2007:
> 
> I'd need to see a more concrete design to be convinced this is a good
> idea.  What would these separate types look like?  How would you
> describe a string with two or more different properties.

Sure, I'm only proposing the idea, not the details.

The idea itself is sound.  About the only two interesting properties
I've ever come across are "does this contain NULs?" and "is this string
safely escaped for scripting/CGI/whatever purposes?"  I'd guess these
things would be handled by application specific data types.

> Anyway, strings containing nulls are the wrong default, and probably
> shouldn't be allowed at all.

I don't see why.

> Also, string construction code is a large part of the cost of reading
> Mercury source files (which is why a lot of it is done in C), so invoking
> a general mechanism for every character of Mercury source is going to be
> a significant performance hit for the compiler.

(Haven't you seen the IO streams proposal that was introduced recently :-)

If I were to write that part of the compiler from scratch, I'd read
entire files in as strings and then parse them.  All that char-at-a-time
nonsense is unsurprisingly slow.  Still, I thought the compiler spent a
relatively small amount of time doing IO.

-- Ralph
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------