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

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

str_replace does not like empty quotes

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

Contents

  str_replace does not like empty quotes richard <noreply@example.com> - 2014-06-19 19:33 -0400
    Re: str_replace does not like empty quotes Jerry Stuckle <jstucklex@attglobal.net> - 2014-06-19 20:09 -0400
    Re: str_replace does not like empty quotes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-06-19 20:11 -0400
      Re: str_replace does not like empty quotes Jerry Stuckle <jstucklex@attglobal.net> - 2014-06-19 20:55 -0400
      Re: str_replace does not like empty quotes Doug Miller <doug_at_milmac_dot_com@example.com> - 2014-06-20 03:23 +0000
      Re: str_replace does not like empty quotes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-20 09:31 +0200
    Re: str_replace does not like empty quotes Arno Welzel <usenet@arnowelzel.de> - 2014-06-20 03:19 +0200
      Re: str_replace does not like empty quotes Arno Welzel <usenet@arnowelzel.de> - 2014-06-20 03:21 +0200
        Re: str_replace does not like empty quotes Jerry Stuckle <jstucklex@attglobal.net> - 2014-06-19 21:33 -0400
          Re: str_replace does not like empty quotes Arno Welzel <usenet@arnowelzel.de> - 2014-06-20 04:06 +0200
            Re: str_replace does not like empty quotes Jerry Stuckle <jstucklex@attglobal.net> - 2014-06-19 22:26 -0400
      Re: str_replace does not like empty quotes richard <noreply@example.com> - 2014-06-19 22:13 -0400
        Re: str_replace does not like empty quotes Doug Miller <doug_at_milmac_dot_com@example.com> - 2014-06-20 03:26 +0000
        Re: str_replace does not like empty quotes Arno Welzel <usenet@arnowelzel.de> - 2014-06-20 11:01 +0200
          Re: str_replace does not like empty quotes Arno Welzel <usenet@arnowelzel.de> - 2014-06-20 11:02 +0200
            Re: str_replace does not like empty quotes Denis McMahon <denismfmcmahon@gmail.com> - 2014-06-20 15:38 +0000
        Re: str_replace does not like empty quotes Denis McMahon <denismfmcmahon@gmail.com> - 2014-06-20 15:32 +0000
    Re: str_replace does not like empty quotes Denis McMahon <denismfmcmahon@gmail.com> - 2014-06-20 01:59 +0000
    Re: str_replace does not like empty quotes Doug Miller <doug_at_milmac_dot_com@example.com> - 2014-06-20 03:25 +0000
    Re: str_replace does not like empty quotes Geoff Muldoon <geoff.muldoon@trap.gmail.com> - 2014-06-20 16:10 +1000
      Re: str_replace does not like empty quotes Christoph Michael Becker <cmbecker69@arcor.de> - 2014-06-20 13:48 +0200
        Re: str_replace does not like empty quotes Denis McMahon <denismfmcmahon@gmail.com> - 2014-06-20 15:40 +0000
        Re: str_replace does not like empty quotes Geoff Muldoon <geoff.muldoon@trap.gmail.com> - 2014-06-22 10:05 +1000
          Re: str_replace does not like empty quotes Jerry Stuckle <jstucklex@attglobal.net> - 2014-06-21 20:08 -0400
            Re: str_replace does not like empty quotes Geoff Muldoon <geoff.muldoon@trap.gmail.com> - 2014-06-23 09:20 +1000
              Re: str_replace does not like empty quotes Jerry Stuckle <jstucklex@attglobal.net> - 2014-06-22 20:44 -0400
                Re: str_replace does not like empty quotes Geoff Muldoon <geoff.muldoon@trap.gmail.com> - 2014-06-23 16:33 +1000
                  Re: str_replace does not like empty quotes Jerry Stuckle <jstucklex@attglobal.net> - 2014-06-23 09:07 -0400
                    Re: str_replace does not like empty quotes Geoff Muldoon <geoff.muldoon@trap.gmail.com> - 2014-06-24 12:34 +1000
                      Re: str_replace does not like empty quotes Jerry Stuckle <jstucklex@attglobal.net> - 2014-06-23 23:07 -0400
                      Re: str_replace does not like empty quotes Doug Miller <doug_at_milmac_dot_com@example.com> - 2014-06-24 11:12 +0000
                        Re: str_replace does not like empty quotes Jerry Stuckle <jstucklex@attglobal.net> - 2014-06-24 08:01 -0400
    Re: str_replace does not like empty quotes Olaf Schmitt <thesys@gmx.de> - 2014-06-24 08:13 +0200
      Re: str_replace does not like empty quotes Arno Welzel <usenet@arnowelzel.de> - 2014-06-24 10:44 +0200
        Re: str_replace does not like empty quotes Denis McMahon <denismfmcmahon@gmail.com> - 2014-06-24 18:48 +0000
          Re: str_replace does not like empty quotes Christoph Michael Becker <cmbecker69@arcor.de> - 2014-06-24 21:53 +0200
            Re: str_replace does not like empty quotes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-24 22:08 +0200

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

#13929

Geoff Muldoon wrote:

> In article <1kcemjreijezv$.k2q3x4bl6eoc.dlg@40tude.net>, 
> noreply@example.com says...
>  
>> $a=str_replace($a,"\","");
>  
> c) Google PHP stripslashes.

Good point!  However, the need for removing backslashes begs the
question where these backslashes come from in the first place.  I
suppose the cause is <news:itrvizyykmyu$.1m8xc48h8xvgi.dlg@40tude.net>:

| $a=str_replace("'","\'",$a);
| Works just fine.

So much for "works just fine".

-- 
Christoph M. Becker

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

#13936

On Fri, 20 Jun 2014 13:48:24 +0200, Christoph Michael Becker wrote:

> Geoff Muldoon wrote:
> 
>> In article <1kcemjreijezv$.k2q3x4bl6eoc.dlg@40tude.net>,
>> noreply@example.com says...
>>  
>>> $a=str_replace($a,"\","");
>>  
>> c) Google PHP stripslashes.
> 
> Good point!  However, the need for removing backslashes begs the
> question where these backslashes come from in the first place.  I
> suppose the cause is <news:itrvizyykmyu$.1m8xc48h8xvgi.dlg@40tude.net>:
> 
> | $a=str_replace("'","\'",$a);
> | Works just fine.
> 
> So much for "works just fine".

As I said upthread, to richard:

There is a reason that you have been advised in the past to use certain
functions and best practices instead of trying to reinvent them yourself.
This is just another example of your persistent refusal to listen to good
advice biting your arse.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#13979

cmbecker69@arcor.de says...
> 
> Geoff Muldoon wrote:

> > c) Google PHP stripslashes.
> 
> Good point!  However, the need for removing backslashes begs the
> question where these backslashes come from in the first place.

Probably depends amongst other things on whether the database insert 
facility uses strings or bind variables.

Of course, bind variables are massively better, but I doubt that Richard 
is up to knowing about them yet.

GM

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

#13980

On 6/21/2014 8:05 PM, Geoff Muldoon wrote:
> cmbecker69@arcor.de says...
>>
>> Geoff Muldoon wrote:
> 
>>> c) Google PHP stripslashes.
>>
>> Good point!  However, the need for removing backslashes begs the
>> question where these backslashes come from in the first place.
> 
> Probably depends amongst other things on whether the database insert 
> facility uses strings or bind variables.
>

Makes no difference whether strings or bind values are used.  Properly
processed, both work equally well in a database.

> Of course, bind variables are massively better, but I doubt that Richard 
> is up to knowing about them yet.
> 
> GM
> 

One opinion.  But bound values have their problems, also.  They are
neither better nor worse than properly escaping values.  Just another
way of doing things.

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

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

#14001

jstucklex@attglobal.net says...

> > Of course, bind variables are massively better, but I doubt that 
Richard 
> > is up to knowing about them yet.

> One opinion.  But bound values have their problems, also.  They are
> neither better nor worse than properly escaping values.  Just another
> way of doing things.

Hmm, I've never really found any signifcant down-side to using bind 
variables if they are used corrctly, so I'd appreciate any links you 
might have.

IMHO three of the main pluses are:

a) A strong (but not totally foolproof) barrier against SQL injection 
attacks.

b) On certain platforms (perhaps on Oracle more so than MySQL, etc.) the 
ability to shared pool cache or soft-parse rather than hard-parse a 
particular execution plan, often significantly increasing performance 
when querying the same columns from the sames tables.

c) Parameter input values do not NEED to be properly escaped.

http://en.wikipedia.org/wiki/Prepared_statement

GM

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

#14002

On 6/22/2014 7:20 PM, Geoff Muldoon wrote:
> jstucklex@attglobal.net says...
> 
>>> Of course, bind variables are massively better, but I doubt that 
> Richard 
>>> is up to knowing about them yet.
> 
>> One opinion.  But bound values have their problems, also.  They are
>> neither better nor worse than properly escaping values.  Just another
>> way of doing things.
> 
> Hmm, I've never really found any signifcant down-side to using bind 
> variables if they are used corrctly, so I'd appreciate any links you 
> might have.
> 
> IMHO three of the main pluses are:
> 
> a) A strong (but not totally foolproof) barrier against SQL injection 
> attacks.
> 
> b) On certain platforms (perhaps on Oracle more so than MySQL, etc.) the 
> ability to shared pool cache or soft-parse rather than hard-parse a 
> particular execution plan, often significantly increasing performance 
> when querying the same columns from the sames tables.
> 
> c) Parameter input values do not NEED to be properly escaped.
> 
> http://en.wikipedia.org/wiki/Prepared_statement
> 
> GM
> 

Performance, for one.  Bound values require at least one extra call to
the libraries (for the PREPARE).

Additional calls are required to bind numeric values.  Of course they
are also required for string variables, but since strings need to
otherwise be processed through mysql_real_escape_string(), that's a push.

Additionally, values should always be validated before being used in a
mysql request anyway.

The extra processing can be excessive in a busy site.  Of course, if
you're only getting 100 hits/day, it's not a problem.

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

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

#14008

jstucklex@attglobal.net says...
> 
> On 6/22/2014 7:20 PM, Geoff Muldoon wrote:
> > jstucklex@attglobal.net says...

> > Hmm, I've never really found any signifcant down-side to using bind 
> > variables if they are used corrctly, so I'd appreciate any links you 
> > might have.

> Performance, for one.  Bound values require at least one extra call to
> the libraries (for the PREPARE).

> The extra processing can be excessive in a busy site.  Of course, if
> you're only getting 100 hits/day, it's not a problem.

Yes, the first usage of a prepared statement will always require that 
extra call, and if it is a query that is unlikely to be run again before 
it is flushed from the cache, it will require this call again each time.  

However, *particularly if it IS a busy site* and it is a query that is 
likely to be executed with a very high regularity (e.g.: "select <fixed 
list of order details columns> from order_details_table where order_id = 
:<bound variable>") then the benefit of SQL execution plan caching and 
soft instead of hard parsing will usually *massively* outweigh that 
possible initial overhead.

High-volume sites are MORE likely than toy ones to benefit from bind 
variables.

GM

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

#14013

On 6/23/2014 2:33 AM, Geoff Muldoon wrote:
> jstucklex@attglobal.net says...
>>
>> On 6/22/2014 7:20 PM, Geoff Muldoon wrote:
>>> jstucklex@attglobal.net says...
> 
>>> Hmm, I've never really found any signifcant down-side to using bind 
>>> variables if they are used corrctly, so I'd appreciate any links you 
>>> might have.
> 
>> Performance, for one.  Bound values require at least one extra call to
>> the libraries (for the PREPARE).
> 
>> The extra processing can be excessive in a busy site.  Of course, if
>> you're only getting 100 hits/day, it's not a problem.
> 
> Yes, the first usage of a prepared statement will always require that 
> extra call, and if it is a query that is unlikely to be run again before 
> it is flushed from the cache, it will require this call again each time.  
> 
> However, *particularly if it IS a busy site* and it is a query that is 
> likely to be executed with a very high regularity (e.g.: "select <fixed 
> list of order details columns> from order_details_table where order_id = 
> :<bound variable>") then the benefit of SQL execution plan caching and 
> soft instead of hard parsing will usually *massively* outweigh that 
> possible initial overhead.
> 
> High-volume sites are MORE likely than toy ones to benefit from bind 
> variables.
> 
> GM
> 

If it's a busy site, then there will be a lot more calls to MySQL - and
chances are the cache will be filled (and flushed) before the prepared
statement is run again.  It's not how long since the query has run -
it's how many other queries have been run.  Remember it isn't just one
query being run on a site - a large site will have hundreds (or more)
different queries.

And it will still require a call each time, because you never know
whether it has been flushed or not.

Additionally, you ignore the fact additional calls need to be made to
bind numeric values - calls which are not required when not using bind
values.

Have you ever worked on a high-active site?  Say 1K hits/second or more?
 And have you ever profiled bind values on such a site?  I have.  Bind
values are significantly slower.

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

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

#14023

jstucklex@attglobal.net says...
> Have you ever worked on a high-active site?  Say 1K hits/second or 
more?
>  And have you ever profiled bind values on such a site?  I have.  

Most high-activity sites I've worked on have used Oracle rather than 
MySQL, and Oracle is much better at targetting and maintaining bind 
variable execution plans in cache.  You may be right that MySQL gains 
less and could suffer more from using them. 

Additionally, just because a site has high volumes that doesn't 
necessarily mean lots of different SQL statements.  I've worked on very 
high volume sites where 80+% of the database calls are made using less 
than 10 different queries - find a product, add product to order 
(looping), show an order, write an invoice, etc.  In these cases, with 
correct cache size tweaking, performace was substantially improved by 
using bind variables.

GM

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

#14024

On 6/23/2014 10:34 PM, Geoff Muldoon wrote:
> jstucklex@attglobal.net says...
>> Have you ever worked on a high-active site?  Say 1K hits/second or 
> more?
>>  And have you ever profiled bind values on such a site?  I have.  
> 
> Most high-activity sites I've worked on have used Oracle rather than 
> MySQL, and Oracle is much better at targetting and maintaining bind 
> variable execution plans in cache.  You may be right that MySQL gains 
> less and could suffer more from using them. 
> 
> Additionally, just because a site has high volumes that doesn't 
> necessarily mean lots of different SQL statements.  I've worked on very 
> high volume sites where 80+% of the database calls are made using less 
> than 10 different queries - find a product, add product to order 
> (looping), show an order, write an invoice, etc.  In these cases, with 
> correct cache size tweaking, performace was substantially improved by 
> using bind variables.
> 
> GM
> 

It depends on the site.  I've also used Oracle on websites (as well as
DB2 and SQL Server).  Results vary quite a bit.

I've never seen a site where 80+% of the database calls are made with
less than 10 different queries.  But then the sites I've worked on are
typically pretty complicated sites - not simple shopping carts.  If all
you're doing is a shopping cart, then I can see where bind variables
might help.

But just because you find something works better in Oracle doesn't mean
it works better in MySQL.  I find a lot of things work better in DB2,
for instance, than either Oracle or MySQL (try doing recursive SQL in
MySQL, for instance).

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

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

#14027

Geoff Muldoon <geoff.muldoon@trap.gmail.com> wrote in news:MPG.2e138ecff04eddb9d1
@news.albasani.net:

[...]
> Additionally, just because a site has high volumes that doesn't 
> necessarily mean lots of different SQL statements.  

I would argue just the opposite, in fact -- the higher the volume, the more likely that a large 
number of SQL statements are substantially the same.

> I've worked on very 
> high volume sites where 80+% of the database calls are made using less 
> than 10 different queries - find a product, add product to order 
> (looping), show an order, write an invoice, etc.  In these cases, with 
> correct cache size tweaking, performace was substantially improved by 
> using bind variables.

Exactly so.

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

#14029

On 6/24/2014 7:12 AM, Doug Miller wrote:
> Geoff Muldoon <geoff.muldoon@trap.gmail.com> wrote in news:MPG.2e138ecff04eddb9d1
> @news.albasani.net:
> 
> [...]
>> Additionally, just because a site has high volumes that doesn't 
>> necessarily mean lots of different SQL statements.  
> 
> I would argue just the opposite, in fact -- the higher the volume, the more likely that a large 
> number of SQL statements are substantially the same.
> 
>> I've worked on very 
>> high volume sites where 80+% of the database calls are made using less 
>> than 10 different queries - find a product, add product to order 
>> (looping), show an order, write an invoice, etc.  In these cases, with 
>> correct cache size tweaking, performace was substantially improved by 
>> using bind variables.
> 
> Exactly so.
> 

The number of SQL statements is not based on the volume; rather it is
based on what the site does.  If all you have is a shopping cart, the
number of SQL statements is going to be low.  Other sites have a much
larger number of SQL statements.

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

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

#14025

Am 20.06.2014 01:33, schrieb richard:
> $a=str_replace($a,"\","");
$a=str_replace($a,"\\","");

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

#14026

Am 2014-06-24 08:13, schrieb Olaf Schmitt:

> Am 20.06.2014 01:33, schrieb richard:
>> $a=str_replace($a,"\","");
> $a=str_replace($a,"\\","");

JFTR: The order is search, replace, subject and not subject, search,
replace.

So the right solution is:

$a=str_replace("\\", "", $a);

Or just use:

$a = stripslashes($a);

;-)


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#14034

On Tue, 24 Jun 2014 10:44:51 +0200, Arno Welzel wrote:

> Am 2014-06-24 08:13, schrieb Olaf Schmitt:
> 
>> Am 20.06.2014 01:33, schrieb richard:
>>> $a=str_replace($a,"\","");
>> $a=str_replace($a,"\\","");
> 
> JFTR: The order is search, replace, subject and not subject, search,
> replace.

Yes, but richard is using his own definitions for search, replace and 
subject, which only align with the php in the 42nd alternative universe 
across.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#14035

Denis McMahon wrote:

> On Tue, 24 Jun 2014 10:44:51 +0200, Arno Welzel wrote:
> 
>> Am 2014-06-24 08:13, schrieb Olaf Schmitt:
>>
>>> Am 20.06.2014 01:33, schrieb richard:
>>>> $a=str_replace($a,"\","");
>>> $a=str_replace($a,"\\","");
>>
>> JFTR: The order is search, replace, subject and not subject, search,
>> replace.
> 
> Yes, but richard is using his own definitions for search, replace and 
> subject, which only align with the php in the 42nd alternative universe 
> across.

Or maybe he's doing something like the following:

    runkit_function_rename('str_replace', 'php_str_replace');
    runkit_function_add(
        'str_replace', '$subject, $search, $replace',
        'return php_str_replace($search, $replace, $subject);'
    );

    echo str_replace('something', 'some', 'any');

SCNR.

-- 
Christoph M. Becker

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

#14036

Christoph Michael Becker wrote:

> Denis McMahon wrote:
>> Yes, but richard is using his own definitions for search, replace and
>> subject, which only align with the php in the 42nd alternative universe
>> across.
> 
> Or maybe he's doing something like the following:
> 
>     runkit_function_rename('str_replace', 'php_str_replace');
>     runkit_function_add(
>         'str_replace', '$subject, $search, $replace',
>         'return php_str_replace($search, $replace, $subject);'
>     );
> 
>     echo str_replace('something', 'some', 'any');
> 
> SCNR.

He must not forget runkit.internal_override=1 in that case ;-)


Pointed"YMMD"Ears
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [standalone]

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

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

csiph-web