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 <maxlen>
characters instead of <maxlen - 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
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 HEADHello all.
I'd like to continue recent IRC discussion here, to draw more
attention to this issue.At the moment functions
fgets()andfgetss()are broken in
HEAD, as they return <maxlen> characters instead of <maxlen -
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 withfgets()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
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()andfgetss()are broken in HEAD, as they return <maxlen>
characters instead of <maxlen - 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--
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
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/
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/
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 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/
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
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/
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.
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
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.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!"
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/
Hello,
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.
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
Hello,
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.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
Hello,
Hello,
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.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.
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
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?
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 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?
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
"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!"
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
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:
"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!"
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()andfgetss()are broken in HEAD, as they
return <maxlen> characters instead of <maxlen - 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
withfgets()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
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()andfgetss()are broken in HEAD, as they return <maxlen>
characters instead of <maxlen - 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