<div dir="ltr">On Thu, Aug 8, 2013 at 9:55 AM, Hans Wennborg <span dir="ltr"><<a href="mailto:hans@chromium.org" target="_blank">hans@chromium.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Aug 7, 2013 at 11:44 PM, Charles Davis <<a href="mailto:cdavis5x@gmail.com">cdavis5x@gmail.com</a>> wrote:<br>

><br>
>   This flag should be doing more stuff. This flag is supposed to request strict ANSI conformance (according to Microsoft's, uh... "unique" interpretation of that). That means at least (in GCC terms) `-fno-ms-extensions`, in addition to not auto-linking `OLDNAMES.LIB`. (The `/Ze` flag undoes the effects of `/Za`.)<br>

><br>
>   I seem to recall someone from MS on `cfe-dev` (and yes, they do exist!) saying that `/Za` is broken and shouldn't be used (cf. "/Za considered harmful" or some such). Are you sure you want to implement it, given that?<br>

<br>
</div>Right. It's not obvious what we should do for /Za. We can't disable<br>
-fms-compatibility for instance, because then we couldn't parse some<br>
template code that cl.exe would accept under /Za, etc.<br>
<br>
However, since I just added the oldnames.lib thing in a previous<br>
patch, I think it makes sense to hook up this flag as way of turning<br>
that off.<br></blockquote><div><br></div><div>Yeah, I agree there's no real reason to implement all of /Za.  Before this change there was a vague comment saying "there's a cl.exe flag that turns this off", when we could just go right ahead and put it in the code.</div>
<div><br></div><div>I could be convinced that it's better to rip this out and make /Za explicitly unsupported.</div></div></div></div>