Hi Derick, On Sun, Aug 3, 2008 at 6:34 PM, Derick Rethans <[EMAIL PROTECTED]> wrote:
> you're not reading what I said. It does not make one single bit of sense > that a short function gives problems while an enormously long function > is fine. This does *NOT* make sense. If you have no idea either, then > figure it out first before you add silly #pragmas to code. This code broke the VC6 build, that's a fact. A breakage must be fixed, period. I figured out why and fixed it, end of the topic. Let forget the insane amount of warnings in the date code... (top #1 in PHP). And notice that I fix it with the smallest impact possible in the code itself: zero change in the C code, only two little #ifdef but for windows. Are you really annoying me for 6 lines within #ifdef while your code breaks the windows build? If you need more information about the reason, please read: http://msdn.microsoft.com/en-us/library/1dy6t14d(VS.80).aspx > THis sort of > stuff should be handled in the build system anyway with flags to the > compiler for this specific file. I prefer to revert it so that the whole > ext misses out the optimizations for old compilers I do not. The second fix is cleaner and affects only the relevant area. We can remove it as well when we figure out a better solution.That being said, to do it at the build script will not allow such thing, the whole file will be affected. The current solution looks like the perfect one to me, without changing the code itself. >. If we then later > find out what really causes it we can add that work around. Now it feels > like it's added for just "let's hack around things to make it work while > I have no idea why this hack works". I know why it works and it is not a hack but a feature. We use dozen GCC specific features as well (and other windows specific features too) but you don't notice it. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
