1

Closed

IFormattable implementations need to allow for null IFormatProviders

description

The IFormattable.ToString(string, IFormatProvider) implementations in many classes (Latitude, Longitude, Azimuth, Area, etc.) assume that the IFormatProvider parameter will always be non-null, but this is not always the case. When the calling code doesn't explicitly specify a format provider, the .Net framework defaults to CultureInfo.CurrentCulture internally, but it passes a null value (not CultureInfo.CurrentCulture) to the IFormattable.ToString method. It is up to the IFormattable.ToString implementation to default to CultureInfo.CurrentCulture when the IFormatProvider is null.
 
The fix for this bug is relatively simple. For example, here are the first few lines of the IFormattable.ToString method for the Latitude class:
 
public string ToString(string format, IFormatProvider formatProvider)
{
CultureInfo culture = (CultureInfo)formatProvider;
 
if (format == null || format.Length == 0)
   format = "G";
...
...
...
 
The above code already cehcks for a null value in the format parameter. An addition check simply needs to be added for the formatProvider parameter, like so:
 
public string ToString(string format, IFormatProvider formatProvider)
{
CultureInfo culture = (CultureInfo)formatProvider;
 
if (culture == null)
  culture = CultureInfo.CurrentCulture;
 
if (format == null || format.Length == 0)
   format = "G";
...
...
...
Closed Aug 11, 2009 at 1:04 AM by BigstickCarpet

comments

jperson wrote Aug 10, 2009 at 5:14 PM

I appreciate your contribution here and have made you a developer for the project. However, when exactly would somebody want to explicitly pass a null format provider? I can't think of one. In every case, a developer will have some idea as to which culture they want, and if they don't know, they should use an overload such as ToString() or ToString(string).

The top complaint of developers regarding this framework was that the compiled DLL was too large, thus slowing down the load time of their applications. I think it would be preferable to remain mindful of this and the implications of writing validation code versus encouraging developers to use existing overloads.

BigstickCarpet wrote Aug 10, 2009 at 8:38 PM

I didn't mean to imply that the developer was passing a null format provider. If that were the case, then I would agree that it's not the library's job to handle that. What I meant to say was that if the developer doesn't specify the format provider at all, then the code is supposed to default to CurrentCulture. To be honest, I was surprised to see that the .Net framework didn't handle that for you automatically. For example, if I call the String.Format overload that doesn't accept an IFormatProvider:

String.Format("Your position is {0}", position)

...then I would have expected the .Net framework to pass CultureInfo.CurrentCulture to the IFormattable method of the Position struct. But for some reason it passes a null value instead, so it's up to the library to handle it.

jperson wrote Aug 11, 2009 at 12:38 AM

Ahh, I see what you mean. Thanks for clarifying. I, too, would expect String.Format to default to CurrentCulture as well, along with any other method with an overload both with and without an IFormatProvider or CultureInfo object to make .NET apps more globalized.

wrote Aug 11, 2009 at 1:04 AM

Resolved with changeset 39368.

wrote Feb 14, 2013 at 2:49 AM

wrote May 16, 2013 at 8:23 AM