[LLVMdev] API design

David A. Greene greened at obbligato.org
Mon Jul 2 21:24:02 PDT 2007


On Monday 02 July 2007 16:26, Chris Lattner wrote:
> On Sun, 1 Jul 2007, Nick Lewycky wrote:
> > I've been running LLVM with _GLIBCXX_DEBUG (extra checks) turned on to
> > see what would happen, and it's been a complete disaster.

Well, that's a bit harsh, isn't it?  It's finding bugs, just like it's
supposed to.  :)

I believe I've started to run into this one too.  I hit a similar error and
was in the middle of tracking down the source.

> > - Changing the API
> >  a) Template it to take two iterators. This causes code size bloat.

This seems like the right solution to me.  Unless llvm is running on
extremely limited memory embedded systems, the extra code space
shouldn't be an issue.

> > We could also just ignore the problem. I'm not clear on what the effects
> > of that would be in the long term. Is this something we can expect will
> > be changed in C++0x?
>
> I don't think that this issue causes any problems in practice.  The
> biggest bad thing is that it makes the extra checking code apparently
> useless :(

The index operation can imply a dereference on some implementations, 
otherwise the checking code wouldn't have caught it.  In other words, the
standard requires that the memory being indexed by referenceable.  Violating
that could cause all sorts of interesting things, like segmentation faults or 
the sudden sprouting of rose bushes on Dan Gohman's head.

I agree that on common architectures it probably won't cause a problem.
But it still results in undefined behavior.

> > I'd like to get the extra checks working so that they can help find our
> > more subtle bugs. Any idea what we should do here?
>
> I don't really have a good idea, but I also don't want to significantly
> uglify the sourcebase...

Passing two iterators is in the spirit of the standard library, so I don't
consider that uglification.  I understand others may disagree.

In any event, leaving this kind of code in is asking for trouble down the
road.

                                                   -Dave



More information about the llvm-dev mailing list