jonathan.bromley@doulos.com wrote: [...] >> As to the warnings, this proposal >> is too restrictive to vendors, and the LRM generally gives >> wider latitude to implementations with respect to warnings. > > Yes, other people have said the same. As long as everyone is > happy to mandate at least one warning, then it should be easy > to relax and simplify that part of the proposal. I wouldn't be happy about it, but I probably wouldn't oppose the change for that reason as the weaker statement likely still gives sufficient flexibility. I am very concerned about the trajectory of the standard in terms of "warnings". The recent vote in SV-BC where vendors unanimously opposed a warning on any array bound write violation and users unanimously supported the warning is a good indicator. Vendors do not go out of their way to make life miserable for users. We know that warnings about surprising results can be useful; in fact, vendors in general have a vested interest in having reasonable and predictable warnings since it can help to reduce support interactions. At the same time, we *regularly* see users turn off *ALL* warnings since they just don't want to see the noise. Good or bad, that is reality. So when *mandated* warnings are suggested that might impact a vendor's ability to do aggressive optimizations, I will object. I would ask the users to keep that in mind -- we know that users want consistency, but consistency can bear a pretty significant *real* cost in terms of performance and/or a vendor's ability to innovate and be aggressive. If the response is "turn the warnings off to be aggressive", then I don't think the warning should be mandated. Mandating behavior that is *expected* to be violated in most real situations is not good language definition practice and I won't support it. Gord -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri May 1 07:01:59 2009
This archive was generated by hypermail 2.1.8 : Fri May 01 2009 - 07:02:17 PDT