Yitzchak Scott-Thoennes wrote: >On Thu, Jun 30, 2005 at 11:22:46AM +0100, Steve Hay wrote: > > >>But what do you mean by "correctly"? You seem to be meaning "what SUSv3 >>says", whereas I would have thought that "correct" for a given compiler >>is "whatever that compiler's headers say". >> >>You're right that it doesn't hurt (and doesn't warn) to apply the cast >>in the VC++ case, i.e. make them "correct" in the SUSv3 sense, but the >>cast is not required w.r.t. VC++'s own header files so it seems silly to >>do the cast. >> >> > >Ah, we've been talking past each other. > >I was trying to say (and still think) that if you have to use ifdefs, >the case singled out should be the one that doesn't follow standards >and doesn't work with the standards-correct code. > I'm glad that we understand each other now, but I still disagree. I've applied change 25033 using the #ifdef for Borland.
Using the #ifdef for MinGW doesn't single out the case that doesn't follow standards because MinGW is following the standards in as much as it gives a warning. Admittedly it doesn't follow the standards by having the wrong declaration to start with, but then neither does VC++, and we can't single out two cases ;-) (... other than by singling out the other one, which is what I've done!) Furthermore, it so happens that VC++ currently (I'm using VC6) doesn't emit any warning about this, but since it is apparently wrong not to do so it may very well change in future versions to emit a warning like MinGW does. We would then have to not use the cast in the VC++ case either, so Borland would have to be the exception. ------------------------------------------------ Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
