I would at least warn from the driver on its use and clarify that it doesn't have the same semantics as CL's flag. On Aug 8, 2013 11:10 AM, "Reid Kleckner" <[email protected]> wrote:
> On Thu, Aug 8, 2013 at 9:55 AM, Hans Wennborg <[email protected]> wrote: > >> On Wed, Aug 7, 2013 at 11:44 PM, Charles Davis <[email protected]> >> wrote: >> > >> > 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`.) >> > >> > 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? >> >> Right. It's not obvious what we should do for /Za. We can't disable >> -fms-compatibility for instance, because then we couldn't parse some >> template code that cl.exe would accept under /Za, etc. >> >> However, since I just added the oldnames.lib thing in a previous >> patch, I think it makes sense to hook up this flag as way of turning >> that off. >> > > 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. > > I could be convinced that it's better to rip this out and make /Za > explicitly unsupported. > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
