I wouldn't worry about the specific interface of an explicit taint/untaint (whether function, case or language construct). That can easily be adjusted later on.
> -----Original Message----- > From: Wietse Venema [mailto:[EMAIL PROTECTED] > Sent: Friday, December 15, 2006 6:02 PM > To: PHP internals > Subject: Re: [PHP-DEV] Run-time taint support proposal > > Richard Lynch: > > On Fri, December 15, 2006 4:31 pm, Wietse Venema wrote: > > > Even if some taint check is to restrictive at some point in time, > > > the programmer can always overcome it with an explicit action. > > > > Would that require some sort of bogus string > non-manipulation, or do > > you foresee a "untaint" function which does nothing but mark it > > untainted, or are you thinking a new operator?... > > > > I think we've run out of ASCII symbols for operators, actually, so > > don't pick that one. :-) > > Maybe we could use (tainted) and (untainted) typecasts as > suggested elsewhere in this thread. > > For my proof-of-concept tests I implemented taint(), untaint() and > is_tainted() extensions so that I could quickly set up a testbed. > But if there is a better user interface then I have no problem. > > It's too early to say exactly when I will be able to share a > first set of diffs with the community, but I'm sure it will > be taken care of. > > Wietse > > -- > PHP Internals - PHP Runtime Development Mailing List To > unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
