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 2 of 2 — ← Prev page 1 [2]

#14487

On 11/5/2014 10:35 PM, Matthew Carter wrote:
> 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).
> 
> 

The page source IS sent.  Just the invalid character is rendered
according to the charset in current use.  In your example, it very well
could be a diamond with a question, while in other cases it might be
something else.

It all depends on how your terminal is set up.

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

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

#14490

On Wed, 05 Nov 2014 22:35:55 -0500, Matthew Carter wrote:

> 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're still missing the point, in that you're looking at the visual 
representation which is controlled by the character set in use at the 
point of display (whether that's CLI, web page, inside a word document or 
whatever).

We're looking at the internal machine representation of the output of the 
explode function, ie comparing:

explode("\n", str_replace("\r\n", "\n", print_r($t, true)));

with:

explode("\n", str_replace("\r\n", "\n", $t));

although you could probably step back a level and look at the input to 
the explode function, ie compare:

str_replace("\r\n", "\n", print_r($t, true));

with:

str_replace("\r\n", "\n", $t);

or even more fundamentally, compare:

print_r($t, true) === $t

but we're talking about a comparison of the two values made internally 
within the code using the '===' operator, not some arbitrary comparison 
made after the output has been processed by the graphics code of some 
display processor based on some arbitrary data relating to how certain 
numeric values should be presented graphically on a screen based on font 
choices etc.

The only value of using the print_r version that I can see is that it 
will fail more gracefully than str_replace will if you hand it a non 
string parameter, but then the following code probably isn't going to get 
the sort of string it expects, so that may well bomb anyway.

And this is a very lazy (and possibly stupid) way of handling such a 
case, it would be better to detect such a case ($t not being a string) 
earlier and fix it, and in well written code, $t would only not be a 
string if it wasn't defined, because you wouldn't reuse a non string 
variable as a string variable etc.

Checking for $t not being defined would be better done with isdef().

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#14491

Denis McMahon <denismfmcmahon@gmail.com> writes:

> On Wed, 05 Nov 2014 22:35:55 -0500, Matthew Carter wrote:
>
>> 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're still missing the point, in that you're looking at the visual 
> representation which is controlled by the character set in use at the 
> point of display (whether that's CLI, web page, inside a word document or 
> whatever).
>
> We're looking at the internal machine representation of the output of the 
> explode function, ie comparing:
>
> explode("\n", str_replace("\r\n", "\n", print_r($t, true)));
>
> with:
>
> explode("\n", str_replace("\r\n", "\n", $t));
>
> although you could probably step back a level and look at the input to 
> the explode function, ie compare:
>
> str_replace("\r\n", "\n", print_r($t, true));
>
> with:
>
> str_replace("\r\n", "\n", $t);
>
> or even more fundamentally, compare:
>
> print_r($t, true) === $t
>
> but we're talking about a comparison of the two values made internally 
> within the code using the '===' operator, not some arbitrary comparison 
> made after the output has been processed by the graphics code of some 
> display processor based on some arbitrary data relating to how certain 
> numeric values should be presented graphically on a screen based on font 
> choices etc.
>
> The only value of using the print_r version that I can see is that it 
> will fail more gracefully than str_replace will if you hand it a non 
> string parameter, but then the following code probably isn't going to get 
> the sort of string it expects, so that may well bomb anyway.
>
> And this is a very lazy (and possibly stupid) way of handling such a 
> case, it would be better to detect such a case ($t not being a string) 
> earlier and fix it, and in well written code, $t would only not be a 
> string if it wasn't defined, because you wouldn't reuse a non string 
> variable as a string variable etc.
>
> Checking for $t not being defined would be better done with isdef().

I've never heard of isdef() - do you mean isset()? 

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

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

#14509

On Thu, 06 Nov 2014 00:09:02 -0500, Matthew Carter wrote:

> Denis McMahon <denismfmcmahon@gmail.com> writes:

>> Checking for $t not being defined would be better done with isdef().

> I've never heard of isdef() - do you mean isset()?

doh! facepalm! yes I mean isset()

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#14505

Matthew Carter wrote:

> 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).

I can't confirm that.  In my tests a REPLACEMENT CHARACTER is sent and
displayed in both cases.

-- 
Christoph M. Becker

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

#14481

On Wed, 05 Nov 2014 15:51:52 -0500, Matthew Carter wrote:

> 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).

You clearly misunderstand the tests I'm doing. I'm not concerning myself 
with how things appear in a browser, because there was nothing in the 
original post that said anything about a browser.

The comparison that I was doing was, in PHP:

explode("\n", str_replace("\r\n", "\n", print_r($t, true)));

vs

explode("\n", str_replace("\r\n", "\n", $t));

Also 980 is an invalid argument to chr, which takes an ascii (not 
extended ascii) code, so the valid range is strictly 0..127, although it 
appears that chr will happily provide strings of values in the range 
0..255, and for any higher integer value uses the value modulo 256.

Hence:

chr(980) === chr(212)

eg:

$ php -a
Interactive shell

php > echo chr(980) === chr(212);
1
php > exit();
$ 

For the avoidance of any doubt, creating a string using the following 
code and using it for the test gives the same results to both forms of 
the explode function too.

$t="";

for ($i =0; $i<1024;$i++) $t.=chr($i);

Please be sure you understand the question before trying to offer 
answers, otherwise you'll get categorised with richard and tpel.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#14482

On Wed, 05 Nov 2014 10:47:30 -0500, Jerry Stuckle wrote:
> On 11/5/2014 10:07 AM, Denis McMahon wrote:
>> On Tue, 04 Nov 2014 06:20:24 -0800, Dave Patoch wrote:

>>>     explode("\n", str_replace("\r\n", "\n", print_r($message, true)))

>>> and

>>>     explode("\n", str_replace("\r\n", "\n", $message))

>> I've not managed to find an edge case that is handled differently by
>> the two cases

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

I didn't expect to, but I must admit to wondering now if that's true for 
all environments.

It's possible (albeit unlikely) that there is a platform out there where 
an edge case exists with a specific string, but I'm not going to worry 
about it until I come across it.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#14488

On 11/5/2014 9:44 PM, Denis McMahon wrote:
> On Wed, 05 Nov 2014 10:47:30 -0500, Jerry Stuckle wrote:
>> On 11/5/2014 10:07 AM, Denis McMahon wrote:
>>> On Tue, 04 Nov 2014 06:20:24 -0800, Dave Patoch wrote:
> 
>>>>     explode("\n", str_replace("\r\n", "\n", print_r($message, true)))
> 
>>>> and
> 
>>>>     explode("\n", str_replace("\r\n", "\n", $message))
> 
>>> I've not managed to find an edge case that is handled differently by
>>> the two cases
> 
>> You won't.  The code generates the same result in both cases because
>> you're dealing with string.
> 
> I didn't expect to, but I must admit to wondering now if that's true for 
> all environments.
> 
> It's possible (albeit unlikely) that there is a platform out there where 
> an edge case exists with a specific string, but I'm not going to worry 
> about it until I come across it.
> 

The display of the character can vary, depending on the charset in use.
 But the returned data would be the same.

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web