<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 24, 2008, at 2:38 PM, Daniel Dunbar wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><div class="gmail_quote">On Fri, Sep 26, 2008 at 2:18 PM, Chris Lattner <span dir="ltr"><<a href="mailto:sabre@nondot.org">sabre@nondot.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <br> + /// Characteristic_t - This is used to represent whether a file or directory<br> + /// holds normal user code, system code, or system code which is implicitly<br> + /// 'extern "C"' in C++ mode. Entire directories can be tagged with this<br> + /// (this is maintained by DirectoryLookup and friends) as can specific<br> + /// FileIDInfos when a #pragma system_header is seen or various other cases.<br> + ///<br> + enum Characteristic_t {<br> + C_User, C_System, C_ExternCSystem<br> + };<br> +</blockquote><div><br></div><div>Why Characteristic_t? Do we have any precedent for this naming convention?</div><div><br></div><div>Lately I find myself wishing we had some more style guidelines, clang has a rich diversity of naming conventions in it. ;)</div> <div>I don't really want to start a discussion of what is best, I just want things to be self consistent.</div></div></blockquote><br></div><div>You're right, that was a horrible name. I renamed it to 'CharacteristicKind'. We use 'Kind' as the general suffix for enum discriminators.</div><div><br></div><div>-Chris </div></body></html>