Re: Adding path_len to all stream functions in trunk

Ok, I went through all the 5.3 code. This should fix the null poisoning problems in 5.3 without breaking binary compatibility: http://progphp.com/nullpatch.txt There are quite a few places where we can't solve it centrally, so perhaps we need to take the same approach in trunk. This should take care of every issue mentioned here: http://www.madirish.net/?article=436 along with a number of bug reports. I think the only outstanding issue with the patch is whether to show an error message when we hit a null in a filesystem path string. With the Zend part of the patch, right now the error is slightly misleading for code like this: $file = "foo.php\0"; include $file . ".png"; This will output: PHP Warning: include(): Failed opening 'foo.php' for inclusion (include_path='.:') in foo on line 3 Without this patch, this code will of course simply include the foo.php file and ignore the .png extension. -Rasmus On 11/14/10 9:35 PM, Andi Gutmans wrote: > Hi Rasmus, > > Hope I understood the problem correctly. If not, this answer won't make sense :) > I do not see a major problem in passing path_len but wonder how much it'd actually solve > as we end up calling OS APIs that do not accept path_len, no? I assume we don't want to start > searching all these strings for invalid chars before we pass them to the OS. > > Andi > >> -----Original Message----- >> From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com] >> Sent: Sunday, November 14, 2010 11:54 AM >> To: internals >> Subject: [PHP-DEV] Adding path_len to all stream functions in trunk >> >> I think we need to pass along the string length to all the stream functions to >> maintain binary string safety through this code. This would fix annoying >> problems like http://bugs.php.net/39863 and a bunch of >> similar issues. >> Obviously not something we can do in 5.3 without breaking binary compatibility >> though. Although we might be able to do something if we assume only chars >> valid in the current charset is valid in file paths. >> >> Anybody have any other thoughts on this one? >> >> -Rasmus >> >> -- >> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: >> http://www.php.net/unsub.php >