Web lists-archives.com

Re: [PHP] BC break in 7.2 caused by undocumented and unauthorised change

"Peter Cowburn" wrote in message news:CAPg3XxJZTGx-oY1=hJkYt+Wr3CfmU3xJv6XcUNMkKtSgStH6Tw@xxxxxxxxxxxxxx...

Hi Tony,

This is a support list for PHP questions and help; the audience mostly
external to the PHP project itself.

Since your message is clearly meant for consumption by "the internals
group", it should instead have been sent to the internals mailing list at


On 23 May 2018 at 15:50, Tony Marston <TonyMarston@xxxxxxxxxxx> wrote:

I have just upgraded from 7.1.11 to 7.2.5 and have encountered a BC break
due to a change in the behaviour of the session_name() function. I have
been using this function in my code since 2003 and it has always performed
as documented.

When I now run the session_name() function it fails with the message
“Cannot change session name when session is active”. This is a break with
the previous behaviour. The documentation clearly states “Get and/or set
the current session name” which means that this function can be used in
three ways:
•    to get the current session name
•    to set the session name to something else
•    to both get AND set the name at the same time

In my application I allow a user to create multiple browser windows so
that they can view different parts of the application in different windows.
This is done by first creating a clone of the current window in a new
window, then starting a new session in one of the windows using code like
if ($_GET['action'] == 'newsession') {
   $session_name = getNewSessionName();  // user-defined function
header('Location: ' ….); // restart script to use new session name and

The change implemented in 7.2 breaks this behaviour and breaks my code.
Before I reported this as a bug I search the bug database and found
https://bugs.php.net/bug.php?id=75650 which declared this change in
behaviour as “not a bug”. My usage is clearly different, so I reported this
as a new bug in https://bugs.php.net/bug.php?id=76358. Again the
responder replied “this is not a bug” with a long list of lame excuses
which boiled down to the fact that someone had reviewed the behaviour,
didn’t think that it should work that way, and decided arbitrarily to
change it without further ado.

The lamest excuse came from requinix@xxxxxxx who said: “It's clear to me
from the current and past implementations that session_name() was never
meant to alter the current session's name.”

How is it possible to reach such a conclusion when the documentation
clearly states:
“session_name() returns the name of the current session. If name is given,
session_name() will update the session name and return the old session
name.” Notice the use of the word “and”.

I raised the point that this BC break was never the subject of an RFC to
which he replied: “Not all changes to PHP require an RFC”.

I raised the point that no change to session_name was ever discussed and
voted upon in the internals list to which he replied: “This one was
mentioned on the internals list by @yohgaki in mid October 2016 ("Fixing
insane session_start() behaviors")”.

I checked this thread, but there was no mention of session_name, and
certainly no mention of any change in behaviour that would cause a BC break.

I raised the point that no changes to session_name, or the fact that the
change would cause a BC break, ever appeared in any PHP change logs or
documentation, to which he replied that it appeared in a GitHub
conversation. This to me is irrelevant as it never appeared in any official
conversations on the php.internals list.

This whole episode raises serious doubts about the future of PHP if
someone is allowed to make a change to the language, especially a change
which causes a BC break, without following the correct procedures, namely
propose, discuss, then vote. If anyone can make an arbitrary change to the
language without peer review just because they think it should work in a
different way then this could lead to more and more BC breaks which could
then make the language unreliable and unusable for the army of application
developers who have made the language as popular as it now is.

I urge the leaders of the internals group to review this serious breach of
procedure and takes the necessary steps to ensure that it never happens

Tony Marston

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

I would love to, but I have been banned from posting to that group because certain people do not like me complaining about BC breaks. I would be grateful if someone with access to that group could forward this post.


Tony Marston

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php