Re: ustring compose escaping capability



On Wed, 2008-01-23 at 16:51 -0500, Paul Davis wrote:
> On Wed, 2008-01-23 at 17:39 +0100, Balazs Scheidler wrote:
> 
> > In my humble opinion it is totally wrong in the way you describe.
> > 
> > Suppose you have 100 different queries, each 2 different arguments (on
> > average), you state that calling make_legal_sql() 200 times is a safer
> > approach than providing the same functionality in one place in compose?
> > 
> > I'd bet that everyone would forget at least one make_legal_sql()
> > invocation.
> > 
> > What does make_legal_sql() do in your example? I say that everything it
> > does can be done in the escaping mechanism that we described. Under the
> > term "escaping" I mean to do whatever transformation on the string
> > necessary to make it sane in the specific context.
> 
> 
> what happens if I am using compose to build a shell command to be passed
> to system, where the rules for escaping are totally different? For
> example, in a shell script, you cannot put single quotes "inside" other
> single quotes *even if they are escaped". how is compose() supposed to
> know this? 
> 
> sure, if you want to do ustring::sql_compose() then go ahead, but then
> you will also need ustring::python_compose(), ustring::sh_compose(), all
> the way down to ustring::some_language_i_have_forgotten_compose().
> 
> leave compose to do the job of merging strings; use other code to handle
> language-context-specific escaping.

That's the whole point, plugging in a language specific escaping is
simple and can be done by the application. We don't need to add this
code to glibmm, only the possibility to do this in an application.

Maybe this was missing from my description. The only change in glibmm is
the _ability_ to plug in escaping classes by the application. Glibmm
will not get neither SQL nor HTML escaping implementations, that's up to
the application to add.

But while remaining source & binary compatible with glibmm, the
application is free to _reuse_ the code that's already there, not having
to invent its own.

-- 
Bazsi



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]