Edit report at https://bugs.php.net/bug.php?id=74312&edit=1
ID: 74312
Comment by: furun at arcor dot de
Reported by: furun at arcor dot de
Summary: Filter BOMs out of PHP output
Status: Re-Opened
Type: Bug
Package: Unicode Engine related
Operating System: Win7
PHP Version: 7.0.17
Block user comment: N
Private report: N
New Comment:
This is rhetoric to protect a dogma, not a technical argument. If a syntax definition is acting like
a pitfall, it should be changed.
Bug prevention is the contrary of randomness. Human errors are random, and bug prevention takes them
out of the way.
The write development strategies is to see, how many time is a ending newline/empty-char intended,
and how many time coders are stumble over it unintended. And then take unwanted randomness out of
the no-game, if indented newlines/empty-chars are very rare and can be done more explicit.
In the middle of a PHP and HTML mixed script, precision for <?php ?> delimitations makes
sense, and should not be faded.
Tanks that there is no enforcement to use ending ?>, they are useless anyway, specially in near
100% php code scripts.
Smart coders don't write any ending ?> to safe there time.
But i see the empty-char after last ?> as not so buggy like the BOM, but i miss the good infos
and experiences to decide what is best.
A very active php community forum helper maybe can tell, how often this becomes a pitfall, and if it
makes sense to chance definitions.
(Just frequenting forums sometime, i seen it many time, ?>.. seems to be a pitfall for me.)
Previous Comments:
------------------------------------------------------------------------
[2017-04-01 02:40:31] spam2 at rhsoft dot net
> And yes, why not do a implicit trim()
because when i want a gambling machine i use a gambling machine and not a programming language
------------------------------------------------------------------------
[2017-03-31 20:02:20] cmb@php.net
Okay, re-opening and bailing out of this discussion. Thanks!
------------------------------------------------------------------------
[2017-03-31 19:51:45] furun at arcor dot de
> IT WAS written here - anything outside <?php ?> is NOT part of the php script
This is the dev-dogma in question. It is not a technical reason, but a dogma.
php-scripts are written from humans in text files, not from machines in binary files.
And yes, why not do a implicit trim(). There is no technical reason why not. In most cases the extra
empty chars after last "?>" are not indented, a trim() prevents human imperfectness.
(My maintenance script deletes the last ?> and all empty chars after. regex =
"?>\s+$") Explicit newlines can be done in code, in the rare cases where this is
indented.
PHP does implicit ignorer 1 newline after ?>
> where will you start here and where will you stop?
The candle of worms is not so deep, i start by deleting the BOM at [BoF] before <?php, and stop
by trim after ?> [EoF].
Otherwise the PHP community will bug-hunt and work-around and forum-help this even in decades from
now.
Or stop simply by deleting the BOM, in case there are technical reasons not to trim.
------------------------------------------------------------------------
[2017-03-31 13:24:47] spam2 at rhsoft dot net
> If there is a technical reason i miss, it was not written here
IT WAS written here - anything outside <?php ?> is NOT part of the php script - where will you
start here and where will you stop?
the next step when open taht candle of worms is "Uhm if i have linebreaks after ?> in
include files output-buffering, headers and sessins are broken, why does PHP not a implicit
trim()"
------------------------------------------------------------------------
[2017-03-31 13:10:43] furun at arcor dot de
OK, like to summ up the points, and then i leave the discussion here.
Principally it is never a good idea to put a warning shield in front of a stone in the way, "be
careful about the stone", instead of just take him out of the way. Every work-around advice is
a "shield in front of the stone" for maybe long "detour", and should only be
used temporally in development time. In most of the cases is possible and better to take stones
away, even if you have to use "dynamite". (To delete mysql and replace it with mysqli is
"dynamite" for this example, because massive development on php site, and coding
maintenance on the other. But its done now to get "stones" out of the way.)
- You get me wrong if you think i want a fix for me, i fix it already in definite with a maintenance
script, because i don't like to waste me life time for such things. I argue here for a
reduction of wasted developers and users life time. For the fix of a really nasty bug-source, which
could be easy fixed in php, with no compatibility pain. It needs maybe only 1 or few code lines. I
write here a improvement request or bug report, not a help request in a forum. (Thanks anyway to the
writers, for the work around help.)
- "zend.multibyte + zend.detect_unicode", is a "shield in front of the stone".
- "output_buffering", is a "shield in front of the stone".
- "adjust tooling", is a "shield in front of the stone". People use there
favorite tools. It is not a real-life advice, otherwise you can write something like
"don't code bugs", and this bug report would become useless. Obviously real-life
don't work like this.
- "BOMs are meaningless for UTF-8", This is not really true, it tells a editor that he
have to use UTF-8. I had scripts, again from 3. party, with mixed coding (ASCII and UTF8), and
destroyed characters, because the editor was confused. Users use ugly and insecure things like this
"<?php //äöü" to tell the tools to use UTF, and tools this "//Setup VIM:
enc=utf-8 :". File headers are there to tell the software the data type and encoding, the UTF8
BOM is such a header.
- "PHP didn't invent the BOM", is irrelevant, it exists and causes trouble. Browser
developers have understand this and ignore BOMs since long time. (I had in the far past a typical
problem with a JS file, again have to waste hours, and found the BOM-bug in a 3. party code far away
from the buggy behavior. Same as php, and browsers now fix this bug source.)
- "bug reports against third-part", is exactly the waste of time i argue here to stop, as
close as possible to the source, instead of multiplying it to the outside to countless developers
and users, and countless wasted life time hours, and bug reports, and forum workaround helps...
It look for me only like a dev-dogma, without any real-life technical reasons. If there is a
technical reason i miss, it was not written here. Why PHP should not delete [BoF]BOM<?php, AND
even ?>\s+[EoF] issues, (because "?>\s+" it is the same problem type from the other
end of the script).
Specially now where many developers switch from php5 to php7 this could be done, if in some very
rare cases it causes problems.
thanks for reading (if you feel pain of reading this long text... you maybe see the problem ;-), by
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=74312
--
Edit this bug report at https://bugs.php.net/bug.php?id=74312&edit=1