Csound Csound-dev Csound-tekno Search About

Re: [Cs-dev] char*/const char*

Date2007-10-29 14:28
FromMichael Gogins
SubjectRe: [Cs-dev] char*/const char*
Your advice is excellent, as usual. I already do all of these things in new code.

But as far as Csound is concerned, the cost of making the code const correct is large, and in my view the benefit is small. If somebody tries to modify a static string, Csound will crash and we will find out why and fix it (and I don't actually think this is happening). 

I DON'T think 'char *mystring = "xxxx"' should be replaced with 'char mystring[] = "xxx"' for the sake of const correctness! Then, we wouldn't necessarily KNOW that somebody was trying to write to the string. We WANT it to crash so we will find out where and why somebody is doing this.

Regards,
Mike

-----Original Message-----
>From: Erik de Castro Lopo 
>Sent: Oct 29, 2007 2:53 AM
>To: csound-devel@lists.sourceforge.net
>Cc: Michael Gogins , Developer discussions 
>Subject: Re: [Cs-dev] char*/const char*
>
>Michael Gogins wrote:
>
>> I do not think this is a serious problem, and I do not think it needs
>> to be fixed.
>> 
>> Yes, it is true that const correctness is not an outstanding feature of
>> the Csound code. This is because Csound predates it.
>
>First let me state that I am not a Csound developer, just an interested
>outsider.
>
>That said, let me state the main reason why const correctness is 
>worthwhile. Correct const correctness for function parameters is a 
>form a documentation. The read can immediately see that a parameter 
>that is passed as a "const type*" cannot be modified in the called
>function. This makes it easier for coders unfamiliar to a code base 
>to make their way around and understand the code.
>
>> I think we should just live with the warnings,
>
>In my code, I have a policy of fixing warnings whereever possible.
>I also tend to develop with -Werror so that all warnings become
>errors and must be fixed before I can complete compiling. In my
>experience that produces better, more robust code.
>
>> because fixing all of this would be terribly time-consuming
>
>Its only time-comsuming for the person who does it :-).
>
>> and might even have unfortunate side effects. 
>
>If you only work on being const correct for strings and char *
>pointers then the chance of side effects is close to zero since 
>Linux *will* segfault if you try and modify a string literal.
>
>> As the saying goes: "If it ain't broke, don't fix it."
>
>Edsger Dijkstra said "Testing can prove the presence of bugs, but
>never their absence.". The corollary of that is that you can know
>if something is broken, you *cannot* know that it isn't.
>
>Erik
>-- 
>-----------------------------------------------------------------
>Erik de Castro Lopo
>-----------------------------------------------------------------
>"... a discussion of C++'s strengths and flaws always sounds
>like an argument about whether one should face north or east
>when one is sacrificing one's goat to the rain god."
>-- Thant Tessman




-------------------------------------------------------------------------
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/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Date2007-10-29 14:47
From"Felipe Sateler"
SubjectRe: [Cs-dev] char*/const char*
AttachmentsNone  

Date2007-10-29 19:19
FromErik de Castro Lopo
SubjectRe: [Cs-dev] char*/const char*
Michael Gogins wrote:

> I DON'T think 'char *mystring = "xxxx"' should be replaced with 
> 'char mystring[] = "xxx"' for the sake of const correctness!

I agree completely. That is obviously the wrong solution in all but the
tiny minority of cases where you actually do want a modifiable string.


Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
Rule 1: Spammers lie.
Rule 2: If a spammer seems to be telling the truth, see Rule #1.

-------------------------------------------------------------------------
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/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net