Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #14455 > unrolled thread

Purpose for a str_replace with an embedded print_r return

Back to article view | Back to comp.lang.php

Contents

  Purpose for a str_replace with an embedded print_r return Dave Patoch <earthlydilemma@gmail.com> - 2014-11-04 06:20 -0800
    Re: Purpose for a str_replace with an embedded print_r return "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-04 16:08 +0100
      Re: Purpose for a str_replace with an embedded print_r return Dave Patoch <earthlydilemma@gmail.com> - 2014-11-04 07:27 -0800
        Re: Purpose for a str_replace with an embedded print_r return Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-04 16:58 +0100
          Re: Purpose for a str_replace with an embedded print_r return "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-04 18:58 +0100
            Re: Purpose for a str_replace with an embedded print_r return Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-04 13:54 -0500
              Re: Purpose for a str_replace with an embedded print_r return Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-05 14:27 +0100
                Re: Purpose for a str_replace with an embedded print_r return Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-05 08:46 -0500
                  Re: Purpose for a str_replace with an embedded print_r return Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-05 15:32 +0100
                    Re: Purpose for a str_replace with an embedded print_r return Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-05 10:44 -0500
                      Re: Purpose for a str_replace with an embedded print_r return Matthew Carter <m@ahungry.com> - 2014-11-05 15:50 -0500
                        Re: Purpose for a str_replace with an embedded print_r return Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-05 16:59 -0500
                        Re: Purpose for a str_replace with an embedded print_r return "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-05 23:56 +0100
                        Re: Purpose for a str_replace with an embedded print_r return Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-06 04:30 +0100
                          Re: Purpose for a str_replace with an embedded print_r return Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-05 22:53 -0500
    Re: Purpose for a str_replace with an embedded print_r return Denis McMahon <denismfmcmahon@gmail.com> - 2014-11-05 15:07 +0000
      Re: Purpose for a str_replace with an embedded print_r return Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-05 10:47 -0500
        Re: Purpose for a str_replace with an embedded print_r return Matthew Carter <m@ahungry.com> - 2014-11-05 15:51 -0500
          Re: Purpose for a str_replace with an embedded print_r return Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-05 17:00 -0500
            Re: Purpose for a str_replace with an embedded print_r return Matthew Carter <m@ahungry.com> - 2014-11-05 22:35 -0500
              Re: Purpose for a str_replace with an embedded print_r return Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-05 22:55 -0500
              Re: Purpose for a str_replace with an embedded print_r return Denis McMahon <denismfmcmahon@gmail.com> - 2014-11-06 04:26 +0000
                Re: Purpose for a str_replace with an embedded print_r return Matthew Carter <m@ahungry.com> - 2014-11-06 00:09 -0500
                  Re: Purpose for a str_replace with an embedded print_r return Denis McMahon <denismfmcmahon@gmail.com> - 2014-11-06 23:59 +0000
              Re: Purpose for a str_replace with an embedded print_r return "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-06 18:43 +0100
          Re: Purpose for a str_replace with an embedded print_r return Denis McMahon <denismfmcmahon@gmail.com> - 2014-11-06 02:39 +0000
        Re: Purpose for a str_replace with an embedded print_r return Denis McMahon <denismfmcmahon@gmail.com> - 2014-11-06 02:44 +0000
          Re: Purpose for a str_replace with an embedded print_r return Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-05 22:56 -0500

Page 1 of 2  [1] 2  Next page →

#14455 — Purpose for a str_replace with an embedded print_r return

I'm cleaning up a legacy code base and I've been trying to figure out what the
functional difference (other then a few cpu ticks and a bit of memory) is
between:

foreach(
    explode("\n", str_replace("\r\n", "\n", print_r($message, true))) as $msg)

and

foreach(
    explode("\n", str_replace("\r\n", "\n", $message)) as $msg)

That first line seems to have been taken from straight from the php-agi 
library, and after a bunch of experimenting and googling I haven't found any
real information. My suspicions are that this was a workaround for some bug
in php 4.x or possibly to force an error if used with ob_start() but I'm
hoping that someone knows the real purpose for that print_r return.

It peaked my curiosity as I've never seen it before.

Thanks!

[toc] | [next] | [standalone]

#14458

Dave Patoch wrote:

> I'm cleaning up a legacy code base and I've been trying to figure out what the
> functional difference (other then a few cpu ticks and a bit of memory) is
> between:
> 
> foreach(
>     explode("\n", str_replace("\r\n", "\n", print_r($message, true))) as $msg)
> 
> and
> 
> foreach(
>     explode("\n", str_replace("\r\n", "\n", $message)) as $msg)
> 
> That first line seems to have been taken from straight from the php-agi 
> library, and after a bunch of experimenting and googling I haven't found any
> real information. My suspicions are that this was a workaround for some bug
> in php 4.x or possibly to force an error if used with ob_start() but I'm
> hoping that someone knows the real purpose for that print_r return.

What type of value does $message hold? If it is an array or an object,
than the print_r definitely makes a difference; otherwise there isn't
any, AFAIK.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#14459

> What type of value does $message hold?

It's just a plain old string, which is why it confused me.
Thank you for the 2nd opinion!

[toc] | [prev] | [next] | [standalone]

#14462

Dave Patoch wrote:

[restored context]

> Christoph M. Becker wrote:
>> Dave Patoch wrote: 
>>> foreach(
>>>    explode("\n", str_replace("\r\n", "\n", print_r($message, true))) as 
>>>    $msg)
>>>
>>> and
>>> 
>>> foreach(
>>>    explode("\n", str_replace("\r\n", "\n", $message)) as $msg)
>>
>> What type of value does $message hold?
> 
> It's just a plain old string, which is why it confused me.

I think the proper idiom is “to kill two birds with one stone”.  This 
appears to be debug code, and if you pass “true” as second parameter to 
print_r(), it returns the output instead of printing it.

<http://php.net/print_r>

The major advantage of print_r() over echo and print(), which always output 
the *string representation* of a value, is that the type of the first 
parameter does not matter for inspection: if it is a string or a number, the 
result is a string or number; if it is an array, it contains the array keys 
and values; and if it is a reference to an object, it contains the object's 
class name and properties.  var_dump()'s output is more detailed than 
print_r()'s on the one hand, and trimmed at a point on the other, and 
highlighting can be applied to that with Xdebug; but it cannot return the 
output instead (you would have to output_buffer it yourself).

<http://php.net/echo>
<http://php.net/print>
<http://php.net/manual/en/language.oop5.magic.php#object.tostring>
<http://php.net/var_dump>
<http://xdebug.org/>

str_replace() then normalizes the value so that it can be explode()d, for 
“foreach” iteration, without using regular expressions.  This does not 
account for Mac OS < 10.x newlines ("\r"), but there does not appear to be a 
PHP release for those versions (anymore).

<http://php.net/str_replace>
<http://php.net/manual/en/install.php>


You are _not_ posting to a Web forum or bulletin board here, but to a Usenet 
newsgroup where postings are read differently than in the Google Groups Web 
archive, and where they usually expire.  Therefore, please provide 
attribution of quoted material, and a minimum of the context.

<http://www.netmeister.org/news/learn2quote.html>

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#14463

Thomas 'PointedEars' Lahn wrote:

> Dave Patoch wrote:
> 
> [restored context]
> 
>> Christoph M. Becker wrote:
>>> Dave Patoch wrote: 
>>>> foreach(
>>>>    explode("\n", str_replace("\r\n", "\n", print_r($message, true))) as 
>>>>    $msg)
>>>>
>>>> and
>>>>
>>>> foreach(
>>>>    explode("\n", str_replace("\r\n", "\n", $message)) as $msg)
>>>
>>> What type of value does $message hold?
>>
>> It's just a plain old string, which is why it confused me.
> 
> I think the proper idiom is “to kill two birds with one stone”.  This 
> appears to be debug code, and if you pass “true” as second parameter to 
> print_r(), it returns the output instead of printing it.

Good catch! At least a plausible explanation for the strange construct.

> The major advantage of print_r() over echo and print(), which always output 
> the *string representation* of a value, is that the type of the first 
> parameter does not matter for inspection: if it is a string or a number, the 
> result is a string or number; if it is an array, it contains the array keys 
> and values; and if it is a reference to an object, it contains the object's 
> class name and properties.  var_dump()'s output is more detailed than 
> print_r()'s on the one hand, and trimmed at a point on the other, and 
> highlighting can be applied to that with Xdebug; but it cannot return the 
> output instead (you would have to output_buffer it yourself).

If I'm not mistaken, the truncation of var_dump()'s output is only
caused by Xdebug (according to the xdebug.var_display_max_* settings[1]).

[1] <http://xdebug.org/docs/display>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#14464

On 11/4/2014 12:58 PM, Christoph M. Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
> 
>> Dave Patoch wrote:
>>
>> [restored context]
>>
>>> Christoph M. Becker wrote:
>>>> Dave Patoch wrote: 
>>>>> foreach(
>>>>>    explode("\n", str_replace("\r\n", "\n", print_r($message, true))) as 
>>>>>    $msg)
>>>>>
>>>>> and
>>>>>
>>>>> foreach(
>>>>>    explode("\n", str_replace("\r\n", "\n", $message)) as $msg)
>>>>
>>>> What type of value does $message hold?
>>>
>>> It's just a plain old string, which is why it confused me.
>>
>> I think the proper idiom is “to kill two birds with one stone”.  This 
>> appears to be debug code, and if you pass “true” as second parameter to 
>> print_r(), it returns the output instead of printing it.
> 
> Good catch! At least a plausible explanation for the strange construct.
> 
>> The major advantage of print_r() over echo and print(), which always output 
>> the *string representation* of a value, is that the type of the first 
>> parameter does not matter for inspection: if it is a string or a number, the 
>> result is a string or number; if it is an array, it contains the array keys 
>> and values; and if it is a reference to an object, it contains the object's 
>> class name and properties.  var_dump()'s output is more detailed than 
>> print_r()'s on the one hand, and trimmed at a point on the other, and 
>> highlighting can be applied to that with Xdebug; but it cannot return the 
>> output instead (you would have to output_buffer it yourself).
> 
> If I'm not mistaken, the truncation of var_dump()'s output is only
> caused by Xdebug (according to the xdebug.var_display_max_* settings[1]).
> 
> [1] <http://xdebug.org/docs/display>
> 

No, the OP already indicated the value was a simple string, not an array
or object reference, so the print_r() is unnecessary (and potentially
confusing).

I suspect the original programmer just copied some debug code he didn't
understand and inserted it into the script.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14469

Jerry Stuckle wrote:

> On 11/4/2014 12:58 PM, Christoph M. Becker wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> I think the proper idiom is “to kill two birds with one stone”.  This
>>> appears to be debug code, and if you pass “true” as second parameter to
>>> print_r(), it returns the output instead of printing it.
>> 
>> Good catch! At least a plausible explanation for the strange construct.
>> […]
> 
> No, the OP already indicated the value was a simple string, not an array
> or object reference, so the print_r() is unnecessary (and potentially
> confusing).

Which part of “debug code” did you not understand?
 
> I suspect the original programmer just copied some debug code he didn't
> understand and inserted it into the script.

It figures: Never ascribe to competent intent and innocent mistake what can 
be ascribed to incompetence and malice instead :->

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#14470

On 11/5/2014 8:27 AM, the pedantic troll Thomas 'Pointed Head' Lahn wrote:
> Jerry Stuckle wrote:
> 
>> On 11/4/2014 12:58 PM, Christoph M. Becker wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> I think the proper idiom is “to kill two birds with one stone”.  This
>>>> appears to be debug code, and if you pass “true” as second parameter to
>>>> print_r(), it returns the output instead of printing it.
>>>
>>> Good catch! At least a plausible explanation for the strange construct.
>>> […]
>>
>> No, the OP already indicated the value was a simple string, not an array
>> or object reference, so the print_r() is unnecessary (and potentially
>> confusing).
> 
> Which part of “debug code” did you not understand?
>

Which part of "unnecessary code" did you not understand?

>> I suspect the original programmer just copied some debug code he didn't
>> understand and inserted it into the script.
> 
> It figures: Never ascribe to competent intent and innocent mistake what can 
> be ascribed to incompetence and malice instead :->
> 

You are a perfect example of incompetence.  There is no other reason why
someone would add such code to print out a string.

But I never said anything about malice.  You're the only one considering
malice here.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14471

Jerry Stuckle wrote:

> [abuse] Thomas 'Pointed Head' Lahn wrote:
>> Jerry Stuckle wrote:
>>> On 11/4/2014 12:58 PM, Christoph M. Becker wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> I think the proper idiom is “to kill two birds with one stone”.  This
>>>>> appears to be debug code, and if you pass “true” as second parameter
>>>>> to print_r(), it returns the output instead of printing it.
>>>>
>>>> Good catch! At least a plausible explanation for the strange construct.
>>>> […]
>>> No, the OP already indicated the value was a simple string, not an array
>>> or object reference, so the print_r() is unnecessary (and potentially
>>> confusing).
>> Which part of “debug code” did you not understand?
> 
> Which part of "unnecessary code" did you not understand?

It is unnecessary only *in your humble opinion*.  However, in *debug* code 
one wants to have a contingency plan.  One does not want to get the string 
representation of a non-string value when you can inspect the unusual array 
or object instead.

> [abuse]

Just go away.
 
-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#14473

On 11/5/2014 9:32 AM, the pedantic troll Thomas 'Pointed Head' Lahn wrote:
> Jerry Stuckle wrote:
> 
>> [abuse] Thomas 'Pointed Head' Lahn wrote:
>>> Jerry Stuckle wrote:
>>>> On 11/4/2014 12:58 PM, Christoph M. Becker wrote:
>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>> I think the proper idiom is “to kill two birds with one stone”.  This
>>>>>> appears to be debug code, and if you pass “true” as second parameter
>>>>>> to print_r(), it returns the output instead of printing it.
>>>>>
>>>>> Good catch! At least a plausible explanation for the strange construct.
>>>>> […]
>>>> No, the OP already indicated the value was a simple string, not an array
>>>> or object reference, so the print_r() is unnecessary (and potentially
>>>> confusing).
>>> Which part of “debug code” did you not understand?
>>
>> Which part of "unnecessary code" did you not understand?
> 
> It is unnecessary only *in your humble opinion*.  However, in *debug* code 
> one wants to have a contingency plan.  One does not want to get the string 
> representation of a non-string value when you can inspect the unusual array 
> or object instead.
> 
>> [abuse]
> 
> Just go away.
>  
> 

This is why you're so stoopid.  The variable being debugged is a STRING
- as the OP said.  It's not an array.  It's not an object.  It's a
STRING.  But you don't understand the difference.

Yes, please go away.  Pedantic trolls like you are not welcome here.

And on the way out, don't let the door hit you in the butt.  You might
get a brain concussion.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14475

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 11/5/2014 9:32 AM, the pedantic troll Thomas 'Pointed Head' Lahn wrote:
>> Jerry Stuckle wrote:
>> 
>>> [abuse] Thomas 'Pointed Head' Lahn wrote:
>>>> Jerry Stuckle wrote:
>>>>> On 11/4/2014 12:58 PM, Christoph M. Becker wrote:
>>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>>> I think the proper idiom is “to kill two birds with one stone”.  This
>>>>>>> appears to be debug code, and if you pass “true” as second parameter
>>>>>>> to print_r(), it returns the output instead of printing it.
>>>>>>
>>>>>> Good catch! At least a plausible explanation for the strange construct.
>>>>>> […]
>>>>> No, the OP already indicated the value was a simple string, not an array
>>>>> or object reference, so the print_r() is unnecessary (and potentially
>>>>> confusing).
>>>> Which part of “debug code” did you not understand?
>>>
>>> Which part of "unnecessary code" did you not understand?
>> 
>> It is unnecessary only *in your humble opinion*.  However, in *debug* code 
>> one wants to have a contingency plan.  One does not want to get the string 
>> representation of a non-string value when you can inspect the unusual array 
>> or object instead.
>> 
>>> [abuse]
>> 
>> Just go away.
>>  
>> 
>
> This is why you're so stoopid.  The variable being debugged is a STRING
> - as the OP said.  It's not an array.  It's not an object.  It's a
> STRING.  But you don't understand the difference.
>
> Yes, please go away.  Pedantic trolls like you are not welcome here.
>
> And on the way out, don't let the door hit you in the butt.  You might
> get a brain concussion.

I did a quick test and there is a difference between using a plain
string and a string wrapped in print_r when you store a
an invalid character in the string and run the script via mod_php.

Try the following snippet:

<?php
header('Content-type: text/html; charset=utf-8');

$string = chr(980); // Some garbage
echo 'The echo: '.$string;
echo 'The print_r: '.print_r($string, TRUE);
?>

You will notice that the character is not sent to the browser when
passed through print_r (it is via the CLI though, so not sure if this is
a mod_php feature).

Changing the encoding to ISO will pass it in both cases (as it is a
valid character in that set).



-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

[toc] | [prev] | [next] | [standalone]

#14477

On 11/5/2014 3:50 PM, Matthew Carter wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
>> On 11/5/2014 9:32 AM, the pedantic troll Thomas 'Pointed Head' Lahn wrote:
>>> Jerry Stuckle wrote:
>>>
>>>> [abuse] Thomas 'Pointed Head' Lahn wrote:
>>>>> Jerry Stuckle wrote:
>>>>>> On 11/4/2014 12:58 PM, Christoph M. Becker wrote:
>>>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>>>> I think the proper idiom is “to kill two birds with one stone”.  This
>>>>>>>> appears to be debug code, and if you pass “true” as second parameter
>>>>>>>> to print_r(), it returns the output instead of printing it.
>>>>>>>
>>>>>>> Good catch! At least a plausible explanation for the strange construct.
>>>>>>> […]
>>>>>> No, the OP already indicated the value was a simple string, not an array
>>>>>> or object reference, so the print_r() is unnecessary (and potentially
>>>>>> confusing).
>>>>> Which part of “debug code” did you not understand?
>>>>
>>>> Which part of "unnecessary code" did you not understand?
>>>
>>> It is unnecessary only *in your humble opinion*.  However, in *debug* code 
>>> one wants to have a contingency plan.  One does not want to get the string 
>>> representation of a non-string value when you can inspect the unusual array 
>>> or object instead.
>>>
>>>> [abuse]
>>>
>>> Just go away.
>>>  
>>>
>>
>> This is why you're so stoopid.  The variable being debugged is a STRING
>> - as the OP said.  It's not an array.  It's not an object.  It's a
>> STRING.  But you don't understand the difference.
>>
>> Yes, please go away.  Pedantic trolls like you are not welcome here.
>>
>> And on the way out, don't let the door hit you in the butt.  You might
>> get a brain concussion.
> 
> I did a quick test and there is a difference between using a plain
> string and a string wrapped in print_r when you store a
> an invalid character in the string and run the script via mod_php.
> 
> Try the following snippet:
> 
> <?php
> header('Content-type: text/html; charset=utf-8');
> 
> $string = chr(980); // Some garbage
> echo 'The echo: '.$string;
> echo 'The print_r: '.print_r($string, TRUE);
> ?>
> 
> You will notice that the character is not sent to the browser when
> passed through print_r (it is via the CLI though, so not sure if this is
> a mod_php feature).
> 
> Changing the encoding to ISO will pass it in both cases (as it is a
> valid character in that set).
> 
> 
> 

Which is not a difference in output from the code.  It is how the text
is interpreted by the browser.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14479

Matthew Carter wrote:

> I did a quick test and there is a difference between using a plain
> string and a string wrapped in print_r when you store a
> an invalid character in the string and run the script via mod_php.
> 
> Try the following snippet:
> 
> <?php
> header('Content-type: text/html; charset=utf-8');
> 
> $string = chr(980); // Some garbage
> echo 'The echo: '.$string;
> echo 'The print_r: '.print_r($string, TRUE);
> ?>
> 
> You will notice that the character is not sent to the browser when
> passed through print_r (it is via the CLI though, so not sure if this is
> a mod_php feature).
> 
> Changing the encoding to ISO will pass it in both cases (as it is a
> valid character in that set).

According to the documentation[1] chr()

| Returns a one-character string containing the character specified by
| ascii.

However, you're passing 980, which is not a valid ASCII character.
Therefore the behavior of chr() could be regarded as undefined.
However, it seems that "all" PHP versions simply use only the low byte
of the input value, which is 212 (= 0xD4).[2]

While 212 is a valid ISO-8859-X character, it is not a (part of a) valid
UTF-8 sequence.  In a browser, usually invalid UTF-8 sequences are
displayed as Unicode REPLACEMENT CHARACTER (U+FFFD); how these are
displayed in a terminal window depends.

[1] <http://php.net/manual/en/function.chr.php>
[2] <http://3v4l.org/q92Pq>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#14483

Matthew Carter wrote:

> Jerry Stuckle <jstucklex@attglobal.net> writes:
> […] Thomas […] Lahn wrote:
>>> It is unnecessary only *in your humble opinion*.  However, in *debug*
>>> code one wants to have a contingency plan.  One does not want to get the
>>> string representation of a non-string value when you can inspect the
>>> unusual array or object instead.
>>> 
>>>> [abuse]
>>> 
>>> Just go away. 
>>
>> This is why you're so stoopid.  The variable being debugged is a STRING
>> - as the OP said.  It's not an array.  It's not an object.  It's a
>> STRING.  But you don't understand the difference.
>>
>> Yes, please go away.  Pedantic trolls like you are not welcome here.
>>
>> And on the way out, don't let the door hit you in the butt.  You might
>> get a brain concussion.
> 
> I did a quick test and there is a difference between using a plain
> string and a string wrapped in print_r when you store a
> an invalid character in the string and run the script via mod_php.
> […]

Interesting.  However, let us not be sidetracked.  We only know it is a 
string *now*.  The same code is also able to handle the case when it is – 
for whatever reason – *not* a string.  Hence the reasonable assumption that 
it is *debug* code, actually – a possibility that some people are not able 
to consider because of their inflated ego with delusions of omniscience and 
infallibility.

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#14485

On 11/5/2014 10:30 PM, the pedantic troll Thomas 'Pointed Head' Lahn wrote:
> Matthew Carter wrote:
> 
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>> […] Thomas […] Lahn wrote:
>>>> It is unnecessary only *in your humble opinion*.  However, in *debug*
>>>> code one wants to have a contingency plan.  One does not want to get the
>>>> string representation of a non-string value when you can inspect the
>>>> unusual array or object instead.
>>>>
>>>>> [abuse]
>>>>
>>>> Just go away. 
>>>
>>> This is why you're so stoopid.  The variable being debugged is a STRING
>>> - as the OP said.  It's not an array.  It's not an object.  It's a
>>> STRING.  But you don't understand the difference.
>>>
>>> Yes, please go away.  Pedantic trolls like you are not welcome here.
>>>
>>> And on the way out, don't let the door hit you in the butt.  You might
>>> get a brain concussion.
>>
>> I did a quick test and there is a difference between using a plain
>> string and a string wrapped in print_r when you store a
>> an invalid character in the string and run the script via mod_php.
>> […]
> 
> Interesting.  However, let us not be sidetracked.  We only know it is a 
> string *now*.  The same code is also able to handle the case when it is – 
> for whatever reason – *not* a string.  Hence the reasonable assumption that 
> it is *debug* code, actually – a possibility that some people are not able 
> to consider because of their inflated ego with delusions of omniscience and 
> infallibility.
> 

It is a string ALWAYS.  There is no need to handle other cases.  But
only a PEDANTIC TROLL wouldn't understand that.

If it WERE an array or on object, there would other MAJOR problems in
the rest of the code.

Yes, your inflated go and delusions of omniscience and infallibility
would prevent you from understanding such a simple concept.

Your are only a pedantic troll - and are well-known in multiple usenet
newsgroups.

I hope you don't get kicked in the butt - you would probably suffer a
brain concussion.  On second though - maybe you already have.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14472

On Tue, 04 Nov 2014 06:20:24 -0800, Dave Patoch wrote:

> I'm cleaning up a legacy code base and I've been trying to figure out
> what the functional difference (other then a few cpu ticks and a bit of
> memory) is between:
> 
> foreach(
>     explode("\n", str_replace("\r\n", "\n", print_r($message, true))) as
>     $msg)
> 
> and
> 
> foreach(
>     explode("\n", str_replace("\r\n", "\n", $message)) as $msg)

I've not managed to find an edge case that is handled differently by the 
two cases, tried feeding a mixture of single and multi line strings into 
the explodes and used !== to check if the resulting arrays were different.

#!/usr/bin/php
<?php

$test = array( 
    "This is a single line string",
    "This is a multi line string\nThis is line 2 of the string\nAnd here 
is line 3",
    "This is another multi line string\r\nThis is line 2 of the string\r
\nAnd here is line 3",
    "This is a multi line string\nWith a blank line\n\nAnd here is line 
4",
    "This is another multi line string\r\nWith a blank line\r\n\r\nAnd 
here is line 4",
<<<EOT
Blah Blah Blah
Blah bloody blah
Pointy eared blah
EOT
);

foreach ($test as $t) {
    $r1 = explode("\n", str_replace("\r\n", "\n", print_r($t, true)));
    $r2 = explode("\n", str_replace("\r\n", "\n", $t));
    if ($r1 !== $r2) echo "\n\n{$t}\n\n differs\n";
    }

echo "Tests complete\n";

?>

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#14474

On 11/5/2014 10:07 AM, Denis McMahon wrote:
> On Tue, 04 Nov 2014 06:20:24 -0800, Dave Patoch wrote:
> 
>> I'm cleaning up a legacy code base and I've been trying to figure out
>> what the functional difference (other then a few cpu ticks and a bit of
>> memory) is between:
>>
>> foreach(
>>     explode("\n", str_replace("\r\n", "\n", print_r($message, true))) as
>>     $msg)
>>
>> and
>>
>> foreach(
>>     explode("\n", str_replace("\r\n", "\n", $message)) as $msg)
> 
> I've not managed to find an edge case that is handled differently by the 
> two cases, tried feeding a mixture of single and multi line strings into 
> the explodes and used !== to check if the resulting arrays were different.
> 
> #!/usr/bin/php
> <?php
> 
> $test = array( 
>     "This is a single line string",
>     "This is a multi line string\nThis is line 2 of the string\nAnd here 
> is line 3",
>     "This is another multi line string\r\nThis is line 2 of the string\r
> \nAnd here is line 3",
>     "This is a multi line string\nWith a blank line\n\nAnd here is line 
> 4",
>     "This is another multi line string\r\nWith a blank line\r\n\r\nAnd 
> here is line 4",
> <<<EOT
> Blah Blah Blah
> Blah bloody blah
> Pointy eared blah
> EOT
> );
> 
> foreach ($test as $t) {
>     $r1 = explode("\n", str_replace("\r\n", "\n", print_r($t, true)));
>     $r2 = explode("\n", str_replace("\r\n", "\n", $t));
>     if ($r1 !== $r2) echo "\n\n{$t}\n\n differs\n";
>     }
> 
> echo "Tests complete\n";
> 
> ?>
> 

Denis,

You won't.  The code generates the same result in both cases because
you're dealing with string.

Now if it were a complex type such as an array or object, the results
would differ.  But the OP already indicated it's a string, so the extra
call to print_r() is superfluous (and confusing).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14476

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 11/5/2014 10:07 AM, Denis McMahon wrote:
>> On Tue, 04 Nov 2014 06:20:24 -0800, Dave Patoch wrote:
>> 
>>> I'm cleaning up a legacy code base and I've been trying to figure out
>>> what the functional difference (other then a few cpu ticks and a bit of
>>> memory) is between:
>>>
>>> foreach(
>>>     explode("\n", str_replace("\r\n", "\n", print_r($message, true))) as
>>>     $msg)
>>>
>>> and
>>>
>>> foreach(
>>>     explode("\n", str_replace("\r\n", "\n", $message)) as $msg)
>> 
>> I've not managed to find an edge case that is handled differently by the 
>> two cases, tried feeding a mixture of single and multi line strings into 
>> the explodes and used !== to check if the resulting arrays were different.
>> 
>> #!/usr/bin/php
>> <?php
>> 
>> $test = array( 
>>     "This is a single line string",
>>     "This is a multi line string\nThis is line 2 of the string\nAnd here 
>> is line 3",
>>     "This is another multi line string\r\nThis is line 2 of the string\r
>> \nAnd here is line 3",
>>     "This is a multi line string\nWith a blank line\n\nAnd here is line 
>> 4",
>>     "This is another multi line string\r\nWith a blank line\r\n\r\nAnd 
>> here is line 4",
>> <<<EOT
>> Blah Blah Blah
>> Blah bloody blah
>> Pointy eared blah
>> EOT
>> );
>> 
>> foreach ($test as $t) {
>>     $r1 = explode("\n", str_replace("\r\n", "\n", print_r($t, true)));
>>     $r2 = explode("\n", str_replace("\r\n", "\n", $t));
>>     if ($r1 !== $r2) echo "\n\n{$t}\n\n differs\n";
>>     }
>> 
>> echo "Tests complete\n";
>> 
>> ?>
>> 
>
> Denis,
>
> You won't.  The code generates the same result in both cases because
> you're dealing with string.
>
> Now if it were a complex type such as an array or object, the results
> would differ.  But the OP already indicated it's a string, so the extra
> call to print_r() is superfluous (and confusing).

I added to the other thread, but try your tests with:

chr(980);

Under the UTF-8 character set (assuming this is coming from a
browser/over mod_php).

-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

[toc] | [prev] | [next] | [standalone]

#14478

On 11/5/2014 3:51 PM, Matthew Carter wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
>> On 11/5/2014 10:07 AM, Denis McMahon wrote:
>>> On Tue, 04 Nov 2014 06:20:24 -0800, Dave Patoch wrote:
>>>
>>>> I'm cleaning up a legacy code base and I've been trying to figure out
>>>> what the functional difference (other then a few cpu ticks and a bit of
>>>> memory) is between:
>>>>
>>>> foreach(
>>>>     explode("\n", str_replace("\r\n", "\n", print_r($message, true))) as
>>>>     $msg)
>>>>
>>>> and
>>>>
>>>> foreach(
>>>>     explode("\n", str_replace("\r\n", "\n", $message)) as $msg)
>>>
>>> I've not managed to find an edge case that is handled differently by the 
>>> two cases, tried feeding a mixture of single and multi line strings into 
>>> the explodes and used !== to check if the resulting arrays were different.
>>>
>>> #!/usr/bin/php
>>> <?php
>>>
>>> $test = array( 
>>>     "This is a single line string",
>>>     "This is a multi line string\nThis is line 2 of the string\nAnd here 
>>> is line 3",
>>>     "This is another multi line string\r\nThis is line 2 of the string\r
>>> \nAnd here is line 3",
>>>     "This is a multi line string\nWith a blank line\n\nAnd here is line 
>>> 4",
>>>     "This is another multi line string\r\nWith a blank line\r\n\r\nAnd 
>>> here is line 4",
>>> <<<EOT
>>> Blah Blah Blah
>>> Blah bloody blah
>>> Pointy eared blah
>>> EOT
>>> );
>>>
>>> foreach ($test as $t) {
>>>     $r1 = explode("\n", str_replace("\r\n", "\n", print_r($t, true)));
>>>     $r2 = explode("\n", str_replace("\r\n", "\n", $t));
>>>     if ($r1 !== $r2) echo "\n\n{$t}\n\n differs\n";
>>>     }
>>>
>>> echo "Tests complete\n";
>>>
>>> ?>
>>>
>>
>> Denis,
>>
>> You won't.  The code generates the same result in both cases because
>> you're dealing with string.
>>
>> Now if it were a complex type such as an array or object, the results
>> would differ.  But the OP already indicated it's a string, so the extra
>> call to print_r() is superfluous (and confusing).
> 
> I added to the other thread, but try your tests with:
> 
> chr(980);
> 
> Under the UTF-8 character set (assuming this is coming from a
> browser/over mod_php).
> 

Yes, and as I said in the other post.  This is not a difference in the
output from the code - it is how it is interpreted by the browser.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14484

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 11/5/2014 3:51 PM, Matthew Carter wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>> 
>>> On 11/5/2014 10:07 AM, Denis McMahon wrote:
>>>> On Tue, 04 Nov 2014 06:20:24 -0800, Dave Patoch wrote:
>>>>
>>>>> I'm cleaning up a legacy code base and I've been trying to figure out
>>>>> what the functional difference (other then a few cpu ticks and a bit of
>>>>> memory) is between:
>>>>>
>>>>> foreach(
>>>>>     explode("\n", str_replace("\r\n", "\n", print_r($message, true))) as
>>>>>     $msg)
>>>>>
>>>>> and
>>>>>
>>>>> foreach(
>>>>>     explode("\n", str_replace("\r\n", "\n", $message)) as $msg)
>>>>
>>>> I've not managed to find an edge case that is handled differently by the 
>>>> two cases, tried feeding a mixture of single and multi line strings into 
>>>> the explodes and used !== to check if the resulting arrays were different.
>>>>
>>>> #!/usr/bin/php
>>>> <?php
>>>>
>>>> $test = array( 
>>>>     "This is a single line string",
>>>>     "This is a multi line string\nThis is line 2 of the string\nAnd here 
>>>> is line 3",
>>>>     "This is another multi line string\r\nThis is line 2 of the string\r
>>>> \nAnd here is line 3",
>>>>     "This is a multi line string\nWith a blank line\n\nAnd here is line 
>>>> 4",
>>>>     "This is another multi line string\r\nWith a blank line\r\n\r\nAnd 
>>>> here is line 4",
>>>> <<<EOT
>>>> Blah Blah Blah
>>>> Blah bloody blah
>>>> Pointy eared blah
>>>> EOT
>>>> );
>>>>
>>>> foreach ($test as $t) {
>>>>     $r1 = explode("\n", str_replace("\r\n", "\n", print_r($t, true)));
>>>>     $r2 = explode("\n", str_replace("\r\n", "\n", $t));
>>>>     if ($r1 !== $r2) echo "\n\n{$t}\n\n differs\n";
>>>>     }
>>>>
>>>> echo "Tests complete\n";
>>>>
>>>> ?>
>>>>
>>>
>>> Denis,
>>>
>>> You won't.  The code generates the same result in both cases because
>>> you're dealing with string.
>>>
>>> Now if it were a complex type such as an array or object, the results
>>> would differ.  But the OP already indicated it's a string, so the extra
>>> call to print_r() is superfluous (and confusing).
>> 
>> I added to the other thread, but try your tests with:
>> 
>> chr(980);
>> 
>> Under the UTF-8 character set (assuming this is coming from a
>> browser/over mod_php).
>> 
>
> Yes, and as I said in the other post.  This is not a difference in the
> output from the code - it is how it is interpreted by the browser.

Jerry - this is not a case of browser encoding it differently - put the
snippet in a page and do a curl call via CLI to the page.

You will see it is simply never sent in the page source (although the
invalid character is shown in the page render/source itself as the black
diamond with a question in the plain "echo" occurence, it is omitted
entirely when done through print_r (no black diamond or any character of
any sort is sent).


-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web