Sigh, I could have edited that better, but I think the apology came across (:
This is still a thing worth fixing. On Sun, Mar 11, 2012 at 6:09 PM, Tom Boutell <t...@punkave.com> wrote: > I do see now that at curl did introduce the @ craziness. So it is unfair > of me to single out PHP for introducing it. I'm not sure if the @ syntax is > a sneaky feature of the standard C API, but it's definitely a sneaky > feature of the command line utility. > > I did include a comment there when I first opened that bug report, > proposing a more appropriate and sustainable interface. Documentation > changes would make it possible to avoid the problem by looking carefully > for strange "gotchas" in the fine print - but not to actually submit a > value starting with a @, if, y'know, I wanted to do something crazy-nutty > like send arbitrary data legal in any other form submission (: > > Apologies for hijacking the discussion. > > The '@' business does not come from libcurl. Native C libcurl > > On Sun, Mar 11, 2012 at 3:38 PM, Pierre Joye <pierre....@gmail.com> wrote: > >> hi Tom, >> >> For one, it is mapped to the libcurl constants and behavior. >> >> Also this but report contains clear comment about this issue being a >> documentation problem, contribution welcome :) >> >> If you consider it as something that should be changed, then please >> feel free to add a comment there as well, or a patch :) >> >> But that's not really what we discuss here but the new code proposed >> by Pierrick. >> >> Cheers, >> >> On Sun, Mar 11, 2012 at 4:22 PM, Tom Boutell <t...@punkave.com> wrote: >> > I'd sure like a PHP extension that didn't have this obvious and nasty >> bug: >> > >> > https://bugs.php.net/bug.php?id=46439 >> > >> > On Sun, Mar 11, 2012 at 3:33 AM, Stas Malyshev <smalys...@sugarcrm.com >> >wrote: >> > >> >> Hi! >> >> >> >> >> >> I wanted to make this new version available in PHP5.4 but >> >>> unfortunately I did finish my work when it was already in RC phase. >> >>> The question now is should we include this new version in PHP5.4.1 or >> >>> should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is >> >>> no feature break (AFAIK) so all the previous code should work as >> >>> expected. You'll find the list of new features attached and the last >> >>> code in the trunk branch. >> >>> >> >> >> >> Can't you make it also available as pecl extension, which could be >> built >> >> on 5.4? This way people could enjoy the benefits of your work without >> >> stable branch being disrupted and BC problems raised. >> >> >> >> -- >> >> Stanislav Malyshev, Software Architect >> >> SugarCRM: http://www.sugarcrm.com/ >> >> (408)454-6900 ext. 227 >> >> >> >> >> >> -- >> >> PHP Internals - PHP Runtime Development Mailing List >> >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >> >> >> > >> > >> > -- >> > Tom Boutell >> > P'unk Avenue >> > 215 755 1330 >> > punkave.com >> > window.punkave.com >> >> >> >> -- >> Pierre >> >> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org >> > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com > > -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com
