Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.std.c++
Subject: Re: casting "const" to "non-const"
Message-ID: <56634@microsoft.UUCP>
Date: 16 Aug 90 18:39:57 GMT
References: <56159@microsoft.UUCP> <56163@microsoft.UUCP> <1029@lupine.NCD.COM>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 28

In article <1029@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>Note that for:
>
>	extern void foobar (const int i);
>
>It can't make any difference to an optimizing compiler whether or not the
>const is in there or not, or whether or not foobar() enforces it strictly.

I disagree.  A compiler that uses a register passing protocol could
very well enregister a const int i before the call to foobar, expecting
that foobar would not molest it, and then attempt to reuse i without
re-enregistering it.

>>This is to say, the trick of casting to a non-const does not 
>>work on a parameter declared as "const."  Compilers can flag as an error 
>>these situations.
>
>Why so fascist?  I prefer warnings in such cases.

When a programmer writes a routine that plays games that are not portable, 
or may not work in the face of compiler optimizations, thus busting that
routine itself, I think that deserves a warning.

However, when a programmer writes a routine that appears to be correct by
inspection, appears to test out correctly, but in unusual situations can
bust the caller's code -- not the callee's code! -- then I think that
deserves an error.  The resulting bugs would be very insidious to try
to track down.