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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel