# fgets()/fgetss() BC break in HEAD - Thread: https://externals.io/message/26544 - Original archive: https://news-web.php.net/php.internals/26544 - Started by Antony Dovgal on 2006-11-13T21:38:47+00:00 - Messages: 21 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #26544 — Antony Dovgal — 2006-11-13T21:38:47+00:00 URL: https://externals.io/message/26544#26544 Hello all. I'd like to continue recent IRC discussion here, to draw more attention to this issue. At the moment functions `fgets()` and fgetss() are broken in HEAD, as they return characters instead of , as they do in 5.2 (and I'm pretty sure this is the way they used to work since their very first appearance in PHP). So, anybody relying on fgets($fp, 10) to return 9 characters would get 10 characters instead. Yes, this behaviour is not very intuitive for those who are not familiar with `fgets()` in C, but it's well documented and pretty much expected. I believe this is an unreasonable BC break and I strongly believe it should be fixed. There are 0 reasons to do it (without any discussion) and it can only result in more users' confusion, even if the original purpose was the contrary. -- Wbr, Antony Dovgal --- ## #26548 — Andi Gutmans — 2006-11-14T05:26:23+00:00 URL: https://externals.io/message/26544#26548 · In reply to: #26544 Sounds like something which indeed isn't worth breaking. Was this intentional? > -----Original Message----- > From: Antony Dovgal [mailto:antony@zend.com] > Sent: Monday, November 13, 2006 1:39 PM > To: php-dev > Subject: [PHP-DEV] `fgets()`/fgetss() BC break in HEAD > > Hello all. > > I'd like to continue recent IRC discussion here, to draw more > attention to this issue. > > At the moment functions `fgets()` and fgetss() are broken in > HEAD, as they return characters instead of 1>, as they do in 5.2 (and I'm pretty sure this is the way > they used to work since their very first appearance in PHP). > So, anybody relying on fgets($fp, 10) to return 9 characters > would get 10 characters instead. > > Yes, this behaviour is not very intuitive for those who are > not familiar with `fgets()` in C, but it's well documented and > pretty much expected. > > I believe this is an unreasonable BC break and I strongly > believe it should be fixed. > There are 0 reasons to do it (without any discussion) and it > can only result in more users' confusion, even if the > original purpose was the contrary. > > -- > Wbr, > Antony Dovgal > > -- > To > unsubscribe, visit: http://www.php.net/unsub.php --- ## #26550 — Richard Quadling — 2006-11-14T08:24:13+00:00 URL: https://externals.io/message/26544#26550 · In reply to: #26544 As we are often told on this list, PHP is not C. It seems utterly ridiculous to return maxlen-1. Whilst this is sure as hell a BC, it should work "properly". If I ask for 10, I want 10. I wouldn't have asked for 10 otherwise. Having to know the "magic" to get things to work is plainly bad magic. In terms of KISS, 10 means 10. Unless PHP !== KISS therefore 10 === 9. Make the break. Deal with it. It was wrong and now it is fixed. > Hello all. > > I'd like to continue recent IRC discussion here, to draw more attention to this issue. > > At the moment functions `fgets()` and fgetss() are broken in HEAD, as they return > characters instead of , as they do in 5.2 (and I'm pretty sure this is the way > they used to work since their very first appearance in PHP). > So, anybody relying on fgets($fp, 10) to return 9 characters would get 10 characters instead. > > Yes, this behaviour is not very intuitive for those who are not familiar with `fgets()` in C, > but it's well documented and pretty much expected. > > I believe this is an unreasonable BC break and I strongly believe it should be fixed. > There are 0 reasons to do it (without any discussion) and it can only result in more users' confusion, > even if the original purpose was the contrary. > > -- > Wbr, > Antony Dovgal > > -- > > > > -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #26551 — Stanislav Malyshev — 2006-11-14T08:34:46+00:00 URL: https://externals.io/message/26544#26551 · In reply to: #26550 > It seems utterly ridiculous to return maxlen-1. > > Whilst this is sure as hell a BC, it should work "properly". If I ask > for 10, I want 10. I wouldn't have asked for 10 otherwise. Having to > know the "magic" to get things to work is plainly bad magic. It always returned length-1, manual says length-1, so suddenly in version 5.2.1 it starts returning length instead. And now imagine somebody who tries to use this function in his scripts. He should start adding version checks to each invocation of this function or what? Doesn't seem very nice behavior to me. > Make the break. Deal with it. It was wrong and now it is fixed. Yes, and the way to deal with it is to restore the function to its previous functionality, according to documentation and the way it always worked. If you need exact number, you can always use fread. There's absolutely no reason to break 100% of working scripts (since nobody uses the new semantics and everybody uses the old) just to satisfy someone's sense of purity. -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ --- ## #26552 — Stanislav Malyshev — 2006-11-14T08:39:20+00:00 URL: https://externals.io/message/26544#26552 · In reply to: #26551 > It always returned length-1, manual says length-1, so suddenly in > version 5.2.1 it starts returning length instead. And now imagine Didn't notice - it is about HEAD not 5.2. It's less critical then but still as bad. People moving to PHP 6 would have enough things to worry without changing functions semantics and things like that is exactly what would make adoption of new versions slow and painful. -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ --- ## #26553 — Richard Quadling — 2006-11-14T08:41:32+00:00 URL: https://externals.io/message/26544#26553 · In reply to: #26551 Just because it has always done it doesn't mean it always will. That's what BC's are about. If this was to be a BC, having it mid version is not a good idea. Maybe for V6 where a whole LOAD of things are going to change, making it another part of the clean up process would be a better option. > > […] > > It always returned length-1, manual says length-1, so suddenly in > version 5.2.1 it starts returning length instead. And now imagine > somebody who tries to use this function in his scripts. He should start > adding version checks to each invocation of this function or what? > Doesn't seem very nice behavior to me. > > > […] > > Yes, and the way to deal with it is to restore the function to its > previous functionality, according to documentation and the way it always > worked. If you need exact number, you can always use fread. There's > absolutely no reason to break 100% of working scripts (since nobody uses > the new semantics and everybody uses the old) just to satisfy someone's > sense of purity. > -- > Stanislav Malyshev, Zend Products Engineer > stas@zend.com http://www.zend.com/ > > -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #26555 — Stanislav Malyshev — 2006-11-14T08:47:32+00:00 URL: https://externals.io/message/26544#26555 · In reply to: #26553 Richard Quadling wrote: > Just because it has always done it doesn't mean it always will. That's > what BC's are about. BC, as far as I know, is "backwards compatibility". It is *exactly* about "it has always done so and it always will". And unless there's a *very* good reason not to do it, so it should be. > If this was to be a BC, having it mid version is not a good idea. > Maybe for V6 where a whole LOAD of things are going to change, making So let's add one more, just for the fun of it? > it another part of the clean up process would be a better option. There's noting more "clean" in new way than in old way - it's a matter of convention. If might be not an ideal one, but having two conventions is much worse than having one non-ideal convention - you can easily deal with latter and you will really hate the guts of the language developers for the former, once your scripts start to break. -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ --- ## #26557 — Antony Dovgal — 2006-11-14T09:16:05+00:00 URL: https://externals.io/message/26544#26557 · In reply to: #26550 > As we are often told on this list, PHP is not C. > > It seems utterly ridiculous to return maxlen-1. It also might seem ridiculous to have `strlen()` and `str_replace()`, but there are good reasons to have `strlen()` instead of str_len(). > Whilst this is sure as hell a BC, it should work "properly". If I ask > for 10, I want 10. I wouldn't have asked for 10 otherwise. Having to > know the "magic" to get things to work is plainly bad magic. > > In terms of KISS, 10 means 10. In terms of KISS BC means "backward compatibility". If you don't want BC - release your own PHP. > Unless PHP !== KISS therefore 10 === 9. > > Make the break. Deal with it. It was wrong and now it is fixed. "It works this way since PHP3" means "it works right" even if there was a bug in PHP3. That's because thousands of people could rely on this behaviour (which is, I repeat, very well documented and pretty much expected). -- Wbr, Antony Dovgal --- ## #26559 — Richard Quadling — 2006-11-14T10:19:44+00:00 URL: https://externals.io/message/26544#26559 · In reply to: #26557 > "It works this way since PHP3" means "it works right" even if there was a bug in PHP3. > That's because thousands of people could rely on this behaviour (which is, I repeat, > very well documented and pretty much expected). And so why are we losing register_globals? For a LOT of code they work and removing rg is sure as hell a BC for a lot of code. And we move forward without it (along with magic_quotes and other dead wood). I think this is just another one of those "yeah, well, we made a decision a LONG time ago and now we are changing it" for a more consistent approach. Just because it was written down, doesn't mean it is right. (Bible/koran/etc being perfect examples!) -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #26561 — Christian Schneider — 2006-11-14T10:56:28+00:00 URL: https://externals.io/message/26544#26561 · In reply to: #26559 Richard Quadling wrote: > And so why are we losing register_globals? For a LOT of code they work > and removing rg is sure as hell a BC for a lot of code. And we move This was done for *good* reason. You don't gain a lot of security (or even code clearity/brevity) by changing fgets. That's the difference. In favour of reverting, - Chris --- ## #26566 — Ilia Alshanetsky — 2006-11-14T14:27:45+00:00 URL: https://externals.io/message/26544#26566 · In reply to: #26551 > > […] > > It always returned length-1, manual says length-1, so suddenly in > version 5.2.1 it starts returning length instead. And now imagine > somebody who tries to use this function in his scripts. He should > start adding version checks to each invocation of this function or > what? Doesn't seem very nice behavior to me. The comparison Tony made was between <=5.X and PHP 6, I do not believe anyone is suggesting to modify the 5.2.x behavior. Ilia Alshanetsky --- ## #26568 — Richard Quadling — 2006-11-14T14:31:42+00:00 URL: https://externals.io/message/26544#26568 · In reply to: #26566 > > > > > […] > > The comparison Tony made was between <=5.X and PHP 6, I do not > believe anyone is suggesting to modify the 5.2.x behavior. Absolutely. This should be a V6 tidy-up. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #26570 — Stanislav Malyshev — 2006-11-14T17:53:52+00:00 URL: https://externals.io/message/26544#26570 · In reply to: #26566 > The comparison Tony made was between <=5.X and PHP 6, I do not believe > anyone is suggesting to modify the 5.2.x behavior. Yes, I noticed later it's PHP 6, but it does not change a thing - it's still totally unnecessary BC break for the sake of meaningless purism. It adds nothing to the language or functionality and would break a lot of code. It should be fixed to be compatible with previous versions. -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ --- ## #26571 — Pierre — 2006-11-14T17:56:54+00:00 URL: https://externals.io/message/26544#26571 · In reply to: #26570 Hello, > > […] > > Yes, I noticed later it's PHP 6, but it does not change a thing - it's > still totally unnecessary BC break for the sake of meaningless purism. > It adds nothing to the language or functionality and would break a lot > of code. It should be fixed to be compatible with previous versions. I have to agree, it is purely a cosmetic change. "Renaming" the argument can make the purists happier. However, as a counter argument, a quick search in codesearch/koders show that very few people rely on this behavior. --Pierre --- ## #26572 — Antony Dovgal — 2006-11-14T18:04:10+00:00 URL: https://externals.io/message/26544#26572 · In reply to: #26571 > Hello, > > > > […] > > I have to agree, it is purely a cosmetic change. "Renaming" the > argument can make the purists happier. > > However, as a counter argument, a quick search in codesearch/koders > show that very few people rely on this behavior. I don't think the number of people relying on this behaviour changes the fact that it's a BC break. -- Wbr, Antony Dovgal --- ## #26573 — Pierre — 2006-11-14T18:59:38+00:00 URL: https://externals.io/message/26544#26573 · In reply to: #26572 Hello, > > > […] > > I don't think the number of people relying on this behaviour changes the fact that it's a BC break. Indeed no, but I only said that the affected users can be small. But I don't really worry about this issue, if we cannot break such things in major versions, when can we do it (this one or another)? For the record, I'm in favour of changing the name of the argument and restore the old behavior, problem solved. --Pierre --- ## #26579 — Zeev Suraski — 2006-11-14T21:12:24+00:00 URL: https://externals.io/message/26544#26579 · In reply to: #26559 Richard, Really, this has been discussed so many times. Backwards compatibility breakage accumulates. It's not a binary. "If we break something we can break everything since it's broken anyway" is not very convincing. The more you break the worse things are, the more work you have to do in order to migrate. Therefore, whatever breakage we have in any one version has absolutely nothing at all whatsoever in any way shape or form in any jurisdiction on this planet or otherwise to do with introducing another BC break. Zeev At 12:19 14/11/2006, Richard Quadling wrote: > > > […] > >And so why are we losing register_globals? For a LOT of code they work >and removing rg is sure as hell a BC for a lot of code. And we move >forward without it (along with magic_quotes and other dead wood). I >think this is just another one of those "yeah, well, we made a >decision a LONG time ago and now we are changing it" for a more >consistent approach. > >Just because it was written down, doesn't mean it is right. >(Bible/koran/etc being perfect examples!) > > > >-- >----- >Richard Quadling >Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 >"Standing on the shoulders of some very clever giants!" --- ## #26594 — bertrand Gugger — 2006-11-15T02:58:33+00:00 URL: https://externals.io/message/26544#26594 · In reply to: #26544 Bonsoir, Antony Dovgal wrote: > Hello all. > > I'd like to continue recent IRC discussion here, to draw more attention > to this issue. > > At the moment functions `fgets()` and fgetss() are broken in HEAD, as they > return characters instead of , as they do in 5.2 > (and I'm pretty sure this is the way they used to work since their very > first appearance in PHP). > So, anybody relying on fgets($fp, 10) to return 9 characters would get > 10 characters instead. > > Yes, this behaviour is not very intuitive for those who are not familiar > with `fgets()` in C, but it's well documented and pretty much expected. > > I believe this is an unreasonable BC break and I strongly believe it > should be fixed. > There are 0 reasons to do it (without any discussion) and it can only > result in more users' confusion, even if the original purpose was the > contrary. > May I say that this thread looks very funny and that poor people wonder what php will be ? Or I am a troll. -- toggg --- ## #26647 — Antony Dovgal — 2006-11-16T17:04:36+00:00 URL: https://externals.io/message/26544#26647 · In reply to: #26544 The issue is now solved, thank you. EOD > Hello all. > > I'd like to continue recent IRC discussion here, to draw more attention to this issue. > > At the moment functions `fgets()` and fgetss() are broken in HEAD, as they return > characters instead of , as they do in 5.2 (and I'm pretty sure this is the way > they used to work since their very first appearance in PHP). > So, anybody relying on fgets($fp, 10) to return 9 characters would get 10 characters instead. > > Yes, this behaviour is not very intuitive for those who are not familiar with `fgets()` in C, > but it's well documented and pretty much expected. > > I believe this is an unreasonable BC break and I strongly believe it should be fixed. > There are 0 reasons to do it (without any discussion) and it can only result in more users' confusion, > even if the original purpose was the contrary. > -- Wbr, Antony Dovgal --- ## #26673 — Richard Lynch — 2006-11-20T19:08:14+00:00 URL: https://externals.io/message/26544#26673 · In reply to: #26551 > > […] It should have been 10, but a zillion scripts are relying on it doing what it does. Changing something this fundamental, and simple, at anything less than a major release point is insane. Even at a major release, it seems like a rather pointless change -- It will only result in millions (literally) choosing not to adopt the new version. Renaming "maxlen" or whatever it is in the docs and variable name to something less clearly defined as "10 means 10" seems like a much better solution. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? --- ## #26674 — Richard Lynch — 2006-11-20T19:13:38+00:00 URL: https://externals.io/message/26544#26674 · In reply to: #26571 > However, as a counter argument, a quick search in codesearch/koders > show that very few people rely on this behavior. I'm not sure you haven't biased your sample in your test to include only more proficient scripters in the first place... [Or possibly LESS proficient scripters. LOL] The Google results posted previously would seem a bit more balanced for the input sample, imho... Not sure that makes a difference, but worth considering. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?