[cfe-commits] Uninitialized data problem...
jahanian
fjahanian at apple.com
Fri Dec 10 10:14:31 PST 2010
This was fixed in r 121490.
- Fariborz
On Dec 10, 2010, at 10:12 AM, Paul Curtis wrote:
> Hi,
>
> In NamedDecl*Sema::ActOnFunctionDeclarator(...) in SemaDecl.cpp there is a
> path to this, labelled (HACK), where isExplicitSpecialization has not been
> initialized.
>
> bool OverloadableAttrRequired=false; // FIXME: HACK!
> if (!getLangOptions().CPlusPlus) {
> // Perform semantic checking on the function declaration.
> CheckFunctionDeclaration(S, NewFD, Previous, isExplicitSpecialization,
> Redeclaration,
> /*FIXME:*/OverloadableAttrRequired);
> assert((NewFD->isInvalidDecl() || !Redeclaration ||
> Previous.getResultKind() != LookupResult::FoundOverloaded) &&
> "previous declaration set still overloaded");
> }
>
> This is because it, um, it hasn't been (when indexing some of my files--I
> don't quite know which yet).
>
> In one path of ActOnFunctionDeclarator() it is left untouched, hence, adding
> isExplicitSpecialization = false on this branch solves it.
>
> if (!getLangOptions().CPlusPlus) {
> // Determine whether the function was written with a
> // prototype. This true when:
> // - there is a prototype in the declarator, or
> // - the type R of the function is some kind of typedef or other
> reference
> // to a type name (which eventually refers to a function type).
> ...
>
> Attached a patch against the trunk which fixes it for me. Not sure whether
> this is the right fix or not, but at least I don't come a cropper in the
> MSVC debugger any more.
>
> Stylistically, you may wish to set isExplicitSpecialization false with an
> initializer.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore arriving Winter 2010! http://www.soldercore.com
>
> <clang.patch>_______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
More information about the cfe-commits
mailing list