For starters, the basic strings are shared. They don't have any identity in the way objects have and there thus isn't any place to put a flag on them that will propagate in a sane way. Introducing it would add a level of indirection that affects all strings, not only those that uses the flag. It'd also be incompatible with the current strings and we'd have to find seek out every place in the C code that compares strings for equality with svalue1->u.string == svalue2->u.string.
The compatibility issue aside, I think it's designwise ugly to clutter up the default string implementation with features that are needed only rarely, especially if it adds complexity when it isn't used. Objects impersonating strings is a fairly elegant way to avoid that, and I don't see any serious problems handling such objects (speaking from some experience of the Locale.DeferredLocale class which implements localized strings that choose language when they are printed).
Objects are also useful since they provide better typing, e.g. functions like crypt() could only accept a SecretString as the password and thus force the user to not make the mistake of using a normal string for it which is likely to get shown in cleartext in a backtrace. Granted, that can be fixed for builtin strings too by introducing a new builtin type, perhaps "secret_string" or "string(secret)", for them.
/.../ If the builtin strings aren't good enough and pople start coding their own "SecretString" and "FooString" and "BarString", then we'll get the same mess as C++, where the common cry of war is "Death to all strings but basic_string<>!!!"
I suspect this has more to do with C++ strong typing and exceedingly complex operator overloading semantics. What problems are there that we'd get in Pike too?
When adding support for arbitrary string-like objects to all C modules (in particular the I/O and the Crypto code), I fear you get enough added complexity that you end up with more security bugs than you started with.
In what way? The SecretString class appears to be a self-contained data type, and it's fairly easy to reason about the operations it implements.
- A global runtime flag that clears all memory at deallocation
time.
That would cause quite a lot of unnecessary overhead since a program typically handles a lot more strings that don't need it. But of course, given that one adds a flag field to strings (which probably will never happen considering the implementation difficulty), it's not hard to a flag for that too on a per-string basis.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-30 11:24: Subject: Re: OpenSSL wrapper vs Pike's SSL (Was: Bz2)
I think an object implementing string behavior is much better in just about every way.
Why??? To me, there's a big advantage of having *one* single string type. If the builtin strings aren't good enough and pople start coding their own "SecretString" and "FooString" and "BarString", then we'll get the same mess as C++, where the common cry of war is "Death to all strings but basic_string<>!!!"
When adding support for arbitrary string-like objects to all C modules (in particular the I/O and the Crypto code), I fear you get enough added complexity that you end up with more security bugs than you started with.
So if strings need more features, add them to the vanilla string type, and to functions operating on them. Reasonable improvement suggestions so far are
A per-string flag to hide a string in %O output.
A global runtime flag that clears all memory at deallocation time.
/ Niels Möller ()