Bug #74312 [Com]: Filter BOMs out of PHP output
[email protected] ("spam2 at rhsoft dot net")
| Newsgroups | php.bugs |
|---|---|
| Message-ID | <[email protected]> |
Edit report at https://bugs.php.net/bug.php?id=74312&edit=1 ID: 74312 Comment by: spam2 at rhsoft dot net 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 franly, if you did not realize it - i am not a php upstream-developer and so don't need to protect any dogma - i am just a userland php-script developer for 15 years now, have written some hundret thousand lines of php-code and frankly tell you if that are real issues for a developer he RELLAY should stop develop software at all Previous Comments: ------------------------------------------------------------------------ [2017-04-01 13:40:27] furun at arcor dot de 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.) ------------------------------------------------------------------------ [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] [email protected] 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()" ------------------------------------------------------------------------ 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