From mboxrd@z Thu Jan 1 00:00:00 1970 From: patl@cag.lcs.mit.edu (Patrick J. LoPresti) To: mark@codesourcery.com, gcc@gcc.cygnus.com Subject: __typealias qualifier (was Re: type based aliasing again) Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: References: <199909161908.UAA26066@phal.cygnus.co.uk> <19990916122341J.mitchell@codesourcery.com> X-SW-Source: 1999-09n/msg00758.html Message-ID: <19990930180200.oXsIoxI6AAsPxiqx14Dtsoa2czzAjO4z0C2GnuJiwcw@z> >>>>> "mark" == Mark Mitchell writes: mark> I'm not convinced we need to provide a "have your cake and eat mark> it too" mode where you can get the benefits of the optimization mark> without having conforming code. Even if you go to the troule mark> of adding some extra type-qualifiers, attributes, etc., mark> somewhere. Are you prepared to be convinced, or have you already made up your mind? mark> Especially now that people are providing implementations of mark> helpful warnings, it seems fair to say "use mark> -fno-strict-aliasing (either because that's the default, or mark> otherwise) or else write conforming code". At least a few users (e.g., Linus) disagree with you. The code where `__typealias' is most useful is precisely the most performance-critical, where the programmer wants to get at memory as raw bytes. On a modern machine, you do this with int *, not char *. mark> Historically, most of our language extensions have proven mark> ill-specified, to have slightly odd behavior, to significantly mark> complicate the compiler, etc. I would prefer for the `__typealias' proposal to be judged on its own merits, not on its ethnic group. Of course, history is a useful guide. I agree that this extension needs be well-specified, have well-thought-out behavior, and to have a benefit which is worth the maintenance cost. So let's discuss these! mark> I'm not commenting on any specific proposal, but it's very, mark> very hard to get new language features right. There tends to mark> be a huge maintenance cost. But we *have* a specific proposal, with a precise spec, a prototype implementation, and a fair rationale. Why not debate that proposal, instead of resorting to general arguments? mark> IMO, the last thing we want to do is to make GNU C a dialect mark> even more divergent from ANSI/ISO C. This argues against any new extension whatsoever. If this is the only argument against `__typealias' and it turns out to be suffient, you should probably document somewhere that no new GCC extensions will ever be accepted. It would save people's time. - Pat