On 9/4/07, Andy Ross <[EMAIL PROTECTED]> wrote:
> John Denker wrote:
> > 2) It seems vacuous to compare writing via a const char* to
> > writing via a non-const char*, because AFAIK there is no such
> > thing as writing via a const char*. No compiler AFAIK will
> > generate any CPU instructions for it.
>
> Oh, good grief:
>
> $ echo 'void foo(const char* p){*(char*)p=0;}' > tmp.c
> $ gcc -S -c -o - tmp.c
>
> Look! Instructions! I await your further pedantry about this
> not "really" being a const pointer because of the cast, to which
> I will reply that casts like this are precicely the subject of
> discussion (hint: see olaf's patch)...
>
> If it really concerns you, take it to plib-devel. It's not our
> code. The question was whether the constness issues in the
> released plib code are blocking bugs for a new FlightGear
> release. As far as I can see, they are not. Plib's behavior in
> the lines touched by this patch is platform independent.
Note that literal string constants may be allocated in read-only data
section, thus causing segmentation fault at runtime. Try calling your
"foo" function passing a literal string, like this:
$ echo 'void foo(const char* p){*(char*)p=0;} int main() {
foo("test"); return 0; }' > tmp.c
$ gcc tmp.c
$ ./a.out
Segmentation fault
Apart from that, it might have unforeseen consequences if the function
modifies a const argument, as the caller can rightly expect it to be
unchanged and reuse it later.
Don't know if any of this applies to the current plib problem, though.
--
Csaba/Jester
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
