[Mono-dev] [Bug 575813] FileStream doesn't handle errors on Close (disk full, generic error, etc.)

Sebastien Pouliot sebastien.pouliot at gmail.com
Mon Feb 8 09:39:51 EST 2010

On Mon, 2010-02-08 at 15:07 +0200, Alex Shulgin wrote:
> Miguel de Icaza wrote:
> >>> I've filed a somewhat nasty bug a few days back (you may lose your data 
> >>> if you trigger it): https://bugzilla.novell.com/show_bug.cgi?id=575813
> >>>
> >>> I'd really appreciate if someone could take a look at this.
> >> BUMP!  Doesn't anyone think it's a critical bug?
> > 
> > The fix is trivial, the side effects are far reaching and any fix will
> > require a careful review of those side effects.
> > 
> > I would not expect a resolution any time soon.
> Yep, pretty reasonable.  I'm not seriously bitten by this, though I'd 
> wish this didn't occur in the first place. :)
> BTW, couldn't this type of programming errors be caught by lint-like 
> tools for static code analysis?  

Yes. Finding *potential* errors is easy. Automatically spotting errors
that matters, like the above case, inside all the potential errors is
much, much, much harder. 

In this case a return value is ignored. Spotting all ignored values is
not hard [1] but since this is something fairly common, even something
normal [2], it's hard to review every cases (i.e. reading thousands of
lines of "potential" defects logs and manually validating them) unless
they are "well known" patterns [3]. However most cases falls into the
"generally ok" category... (i.e. human eyes required)

[1] Gendarme has a rule for this - but will ignore many cases to remove
noise in the results.

[2] the return value of StringBuilder.Append is generally ignored,
unless it's chained with more Append calls, and that's perfectly legit
(and you don't want to be warned in those cases)

[3] Ignoring return value of calls like String.ToUpper is always bad
(that's an easy one ;-)

> Is any of them used regularly over the 
> mono codebase?

It's not a question of executing (or not, or how often) tools - but the
manpower to go thru all the results and decide which are true and must
be fixed versus the false ones (and the one not worth fixing or the ones
that will need a careful review before a simple fix can be committed).

You're welcome to contribute time to run static analysis tools, like
Gendarme, on mono code base, spot real bugs and report them into


More information about the Mono-devel-list mailing list