Re: string.Format and curly braces
On Fri, Feb 4, 2011 at 12:02 PM, David Kean david.k...@microsoft.com wrote:
I’m really interested in the scenario where you are passing user input as
the format string – do you have user input with placeholders ({0}) that you
need to fill?
His problem is double formatting.
Something like:
string likes = Okay: {0}, I like this: {1}.;
likes = string.Format(likes, Toby, {0}, other items, Robots);
string fullStatement= likes + and I am reachable at {0}.;
fullStatement = string.Format(fullStatement, sy...@example.org);
Clearly, this will result in the statement:
Okay: Toby sy...@example.org, I like this: Robots and I am reachable
at sy...@example.org
And not
Okay: Toby {0}, I like this: Robots and I am reachable at sy...@example.org
Which you could get from appropriately quoting the first {0} after Toby.
I mean, arguably this is pretty confusing anyway. But it may happen if
your app is, as he says, suitably layered and passing things around.
It can also be a security issue if someone builds, say, SQL statements
in this matter, passing in security credentials at the end. Luckily, I
would expect nobody is doing this now (I raised this years ago on a
now-defunct blog).
Anyway, I agree, kind of, with meski. The situation just needs to be
cleaned up. Not much to do. I don't think string.Format is ideal
anyway, but it's the best we've got.
--
Noon Silk
http://dnoondt.wordpress.com/ (Noon Silk) | http://www.mirios.com.au:8081
Fancy a quantum lunch?
http://www.mirios.com.au:8081/index.php?title=Quantum_Lunch
Every morning when I wake up, I experience an exquisite joy — the joy
of being this signature.
string.Format and curly braces
Back to coding ... I diagnosed an app crash today caused by an argument to
string.Format having curly braces inside it. I was doing something like
string.Format(Report title: {0}, title) where title was the string
{Intention} and I'm told this is a perfectly acceptable title.
We all know that you have to escape braces by doubling them in the
arguments, but at what point in an app do you guard against this crash?
Today it was way up in the UI, several months ago I had the same crash way
down in a server logging method. The moderate sized app I'm working on today
has 366 string.Format calls scattered all through it at different levels,
some in a Silverlight app and some on the server side. How on earth do you
globally guard all these calls without making a coding mess? I haven't found
an obvious elegant solution yet. Has anyone else considered this problem?
Sure I could wrap string.Format calls in an another function or create a
string extension method that doubles braces in the arguments, but it seems
clumsy.
Greg
Re: string.Format and curly braces
Does this help?
http://geekswithblogs.net/jonasb/archive/2007/03/05/108023.aspx
On 3 February 2011 15:42, Greg Keogh g...@mira.net wrote:
Back to coding ... I diagnosed an app crash today caused by an argument
to string.Format having curly braces inside it. I was doing something like
string.Format(Report
title: {0}, title) where title was the string {Intention} and I'm told
this is a perfectly acceptable title.
We all know that you have to escape braces by doubling them in the
arguments, but at what point in an app do you guard against this crash?
Today it was way up in the UI, several months ago I had the same crash way
down in a server logging method. The moderate sized app I'm working on today
has 366 string.Format calls scattered all through it at different levels,
some in a Silverlight app and some on the server side. How on earth do you
globally guard all these calls without making a coding mess? I haven't found
an obvious elegant solution yet. Has anyone else considered this problem?
Sure I could wrap string.Format calls in an another function or create a
string extension method that doubles braces in the arguments, but it seems
clumsy.
Greg
RE: string.Format and curly braces
You don't have to escape arguments, for example, below shouldn't crash on any
version of .NET .
We you perhaps instead passing user input as the format string instead? That
you will have to escape.
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On
Behalf Of Greg Keogh
Sent: Wednesday, February 02, 2011 9:42 PM
To: 'ozDotNet'
Subject: string.Format and curly braces
Back to coding ... I diagnosed an app crash today caused by an argument to
string.Format having curly braces inside it. I was doing something like
string.Format(Report title: {0}, title) where title was the string
{Intention} and I'm told this is a perfectly acceptable title.
We all know that you have to escape braces by doubling them in the arguments,
but at what point in an app do you guard against this crash? Today it was way
up in the UI, several months ago I had the same crash way down in a server
logging method. The moderate sized app I'm working on today has 366
string.Format calls scattered all through it at different levels, some in a
Silverlight app and some on the server side. How on earth do you globally guard
all these calls without making a coding mess? I haven't found an obvious
elegant solution yet. Has anyone else considered this problem?
Sure I could wrap string.Format calls in an another function or create a string
extension method that doubles braces in the arguments, but it seems clumsy.
Greg
RE: string.Format and curly braces
You don't have to escape arguments, for example, below shouldn't crash on
any version of .NET .
We you perhaps instead passing user input as the format string instead?
That you will have to escape.
Oops! Sorry, you're right, I had it backwards. The format string contains
{Intention} not the argument.
http://geekswithblogs.net/jonasb/archive/2007/03/05/108023.aspx
This is a well known answer, my puzzle is one of scope of the problem. There
are so many string.Formats in my code (thousands scattered over dozens of
solutions) that I can't find an elegant way of globally intercepting the
problem at the different levels from the UI all the way down to the lowest
back end.
It's not even trivial to identify which of my Format calls are at risk of
the braces crash. Finding them would be like performing a security audit. I
think we all have string formatting time-bombs in our code.
Greg
