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. I think we should just live with the warnings, because fixing all of this would be terribly time-consuming and might even have unfortunate side effects. 

As the saying goes: "If it ain't broke, don't fix it."

Regards,
Mike

-----Original Message-----
>From: Felipe Sateler 
>Sent: Oct 28, 2007 11:49 PM
>To: Developer discussions 
>Subject: [Cs-dev] char*/const char*
>
>With gcc, there are a lot of warnings in the csound code about the 
>conversion to char* from a string literal (eg: char *foo = "something"). I'm 
>wondering if that warning is correct: either the string is modifiable and 
>should not be set to a constant, or the string is not modifiable and should 
>be marked as such. 
>
>Note that while the following code might work, it is mere luck:
>
>char* foo="hello";
>foo[2]='z';
>
>For example, it may affect other sections of the program that use a "hello" 
>literal string (due to string pooling), or break under other situations due 
>to compiler optimizations. Moreover, the string literals may be destroyed 
>after the function ends, so if the data has been passed to, eg, an OENTRY 
>structure, then there is unpredictable behaviour.
>
>Changing this should not be difficult, but it will almost certainly be 
>time-consuming. I have started working on this, but I am not familiar with 
>the csound api, so I'm not sure if some stuff is wrong or not. Basically the 
>question boils down to: are char* variables in several structs really 
>intended to be modifiable or they should be const?
>
>I can't really understand because most of those seem like they should be const 
>to me, but there is code that fails to compile or raises new warnings if I 
>set the const attribute.
>
>So there are 2 questions: is const-correctness a goal worth pursuing? If so, 
>which pointer variables should be const?
>
>PD: of course I don't expect a complete answer to question 2, but a general 
>pointer on determining the answer could be helpful.
>
>-- 
>
>	Felipe Sateler




-------------------------------------------------------------------------
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

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

In general I am with Erik on this.  As a csound developer (and other
software) it has always been my aim to have zero warnings.  There was
a time when this was the case on at least 3 different C compilers.  I
still find it irritating that the SWIG output is not warning-free, and
similar for Loris.
==John ffitch

-------------------------------------------------------------------------
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

Erik de Castro Lopo wrote on 10/29/07 2:53 AM:

>> 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.

A possible "unfortunate side effect" would be having to redefine the
prototypes of some of the API functions or public structs.  This would be
undesirable in my opinion.

Trying to fix const-ness in even one instance of a large existing program
has -- in my experience -- been a headache where the const qualifiers keep
propagating up and down the chain of function calls until you reach a point
where you decide that you do not want to or cannot change some particular
variable.  Then you have to backtrack on everything you did ....

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://anthonykozar.net/


-------------------------------------------------------------------------
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