I've been reading guidelines and coding standards for critical
applications (avionics, motor vehicles, nuclear engineering, space
systems). The consensus of these authors is that coding in C and C++
is suitable for critical embedded systems if a restricted subset of
the language is used and if the code is subjected to thorough testing
and, especially, static analysis.

My question here is: What, as a Csound developer, is your personal
experience with static analysis tools? Which if any of these tools
have you used? Which would you recommend for use in Csound
development?

Regards,
Mike

-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

XCode has a static analysis option. I run it here and there as it
takes a little while to go through, but it brings up some interesting
warnings and bugs.  It uses the static analysis tools built in clang.
For example, it shows in pmidi.c:

Line 228: Array access (from variable 'dev') results in a null pointer
dereference

If you click for more info, it shows the logic of how it got to that,
which is from line 207, if dev == NULL, it can go through that branch
of code, then end up proceeding to line 228.

With Csound5, I'm currently seeing mostly "Dead Store" messages for
variables that are defined but not used. Another example, it found in
schedule.c:

Line 502: The left operand of '<' is a garbage value

If you trace through it, it shows that if on line 460, *p->args[0] ==
SSTRCOD, afterwards you proceed through and on line 499, and i <
argnum (says "assuming i >= argnum), then the value in line 502 for
evt.p[2] can be garbage.

csound_orc_parse.c seems to have a number of logic errors of "Function
call argument is an uninitialized value".

Anyways, I'd say it is particularly useful within XCode as you can
trace through visually (it shows arrows between lines of code to
illustrate how it got to its analysis).

steven


On Wed, May 2, 2012 at 2:36 PM, Michael Gogins  wrote:
> I've been reading guidelines and coding standards for critical
> applications (avionics, motor vehicles, nuclear engineering, space
> systems). The consensus of these authors is that coding in C and C++
> is suitable for critical embedded systems if a restricted subset of
> the language is used and if the code is subjected to thorough testing
> and, especially, static analysis.
>
> My question here is: What, as a Csound developer, is your personal
> experience with static analysis tools? Which if any of these tools
> have you used? Which would you recommend for use in Csound
> development?
>
> Regards,
> Mike
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks. I'm trying to figure out how good CLang is as a static code
analyzer relative to its open source, and proprietary, competition.

One thing I've learned is that in "critical systems" programming
("critical" means, a bug can kill you or cause an expensive accident),
it's common for programmers to use a "modeling system" that generates
C or C++ code. This would be something like a block diagram designer
and, in the code generation part of the designer, there would be
something like a data flow graph of the sort I discussed earlier.

Other interesting things I've learned:

They don't use the heap, they don't use stdio.h, they avoid macros,
they don't allow pointer arithmetic, and there are many many things in
Csound code that would not pass. But they are happy with and committed
to both C and C++ and have pretty much dropped other embedded systems
programming languages.

The heap in Csound has always bothered me. We could declare a huge
array of bytes and just index into that for allocations, reset the
index to 0 in Reset. That would do wonders for our real-time
capabilities and our runtime efficiency. This could be an option or,
perhaps, the default for real-time performance.

I found no discussion of threads, which implies that critical systems
don't use them. Since we do need threads, I will be researching  best
practices in threaded programming.

I'm going to propose some "Programming Guidelines for Csound" for
discussion soon, that will cover some of these points.

Regards,
Mike

On Wed, May 2, 2012 at 12:04 PM, Steven Yi  wrote:
> XCode has a static analysis option. I run it here and there as it
> takes a little while to go through, but it brings up some interesting
> warnings and bugs.  It uses the static analysis tools built in clang.
> For example, it shows in pmidi.c:
>
> Line 228: Array access (from variable 'dev') results in a null pointer
> dereference
>
> If you click for more info, it shows the logic of how it got to that,
> which is from line 207, if dev == NULL, it can go through that branch
> of code, then end up proceeding to line 228.
>
> With Csound5, I'm currently seeing mostly "Dead Store" messages for
> variables that are defined but not used. Another example, it found in
> schedule.c:
>
> Line 502: The left operand of '<' is a garbage value
>
> If you trace through it, it shows that if on line 460, *p->args[0] ==
> SSTRCOD, afterwards you proceed through and on line 499, and i <
> argnum (says "assuming i >= argnum), then the value in line 502 for
> evt.p[2] can be garbage.
>
> csound_orc_parse.c seems to have a number of logic errors of "Function
> call argument is an uninitialized value".
>
> Anyways, I'd say it is particularly useful within XCode as you can
> trace through visually (it shows arrows between lines of code to
> illustrate how it got to its analysis).
>
> steven
>
>
> On Wed, May 2, 2012 at 2:36 PM, Michael Gogins  wrote:
>> I've been reading guidelines and coding standards for critical
>> applications (avionics, motor vehicles, nuclear engineering, space
>> systems). The consensus of these authors is that coding in C and C++
>> is suitable for critical embedded systems if a restricted subset of
>> the language is used and if the code is subjected to thorough testing
>> and, especially, static analysis.
>>
>> My question here is: What, as a Csound developer, is your personal
>> experience with static analysis tools? Which if any of these tools
>> have you used? Which would you recommend for use in Csound
>> development?
>>
>> Regards,
>> Mike
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

And on the security side, there's Alex Sotirov's vulncheck
(http://gcc.vulncheck.org/).

On 5/2/12, Michael Gogins  wrote:
> Thanks. I'm trying to figure out how good CLang is as a static code
> analyzer relative to its open source, and proprietary, competition.
>
> One thing I've learned is that in "critical systems" programming
> ("critical" means, a bug can kill you or cause an expensive accident),
> it's common for programmers to use a "modeling system" that generates
> C or C++ code. This would be something like a block diagram designer
> and, in the code generation part of the designer, there would be
> something like a data flow graph of the sort I discussed earlier.
>
> Other interesting things I've learned:
>
> They don't use the heap, they don't use stdio.h, they avoid macros,
> they don't allow pointer arithmetic, and there are many many things in
> Csound code that would not pass. But they are happy with and committed
> to both C and C++ and have pretty much dropped other embedded systems
> programming languages.
>
> The heap in Csound has always bothered me. We could declare a huge
> array of bytes and just index into that for allocations, reset the
> index to 0 in Reset. That would do wonders for our real-time
> capabilities and our runtime efficiency. This could be an option or,
> perhaps, the default for real-time performance.
>
> I found no discussion of threads, which implies that critical systems
> don't use them. Since we do need threads, I will be researching  best
> practices in threaded programming.
>
> I'm going to propose some "Programming Guidelines for Csound" for
> discussion soon, that will cover some of these points.
>
> Regards,
> Mike
>
> On Wed, May 2, 2012 at 12:04 PM, Steven Yi  wrote:
>> XCode has a static analysis option. I run it here and there as it
>> takes a little while to go through, but it brings up some interesting
>> warnings and bugs.  It uses the static analysis tools built in clang.
>> For example, it shows in pmidi.c:
>>
>> Line 228: Array access (from variable 'dev') results in a null pointer
>> dereference
>>
>> If you click for more info, it shows the logic of how it got to that,
>> which is from line 207, if dev == NULL, it can go through that branch
>> of code, then end up proceeding to line 228.
>>
>> With Csound5, I'm currently seeing mostly "Dead Store" messages for
>> variables that are defined but not used. Another example, it found in
>> schedule.c:
>>
>> Line 502: The left operand of '<' is a garbage value
>>
>> If you trace through it, it shows that if on line 460, *p->args[0] ==
>> SSTRCOD, afterwards you proceed through and on line 499, and i <
>> argnum (says "assuming i >= argnum), then the value in line 502 for
>> evt.p[2] can be garbage.
>>
>> csound_orc_parse.c seems to have a number of logic errors of "Function
>> call argument is an uninitialized value".
>>
>> Anyways, I'd say it is particularly useful within XCode as you can
>> trace through visually (it shows arrows between lines of code to
>> illustrate how it got to its analysis).
>>
>> steven
>>
>>
>> On Wed, May 2, 2012 at 2:36 PM, Michael Gogins 
>> wrote:
>>> I've been reading guidelines and coding standards for critical
>>> applications (avionics, motor vehicles, nuclear engineering, space
>>> systems). The consensus of these authors is that coding in C and C++
>>> is suitable for critical embedded systems if a restricted subset of
>>> the language is used and if the code is subjected to thorough testing
>>> and, especially, static analysis.
>>>
>>> My question here is: What, as a Csound developer, is your personal
>>> experience with static analysis tools? Which if any of these tools
>>> have you used? Which would you recommend for use in Csound
>>> development?
>>>
>>> Regards,
>>> Mike
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond.
>>> Discussions
>>> will include endpoint security, mobile security and the latest in
>>> malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Well, I have encountered difficulties when memory is not allocated dynamically. When I was helping with the Faust Csound arch, one of the first problems I saw was that the opcodes would crash when the Faust object was not created dynamically, because of memory issues. Quickly fixed by tapping into the AuxAlloc mechanism. I did not do an extensive analysis at the time, so I cannot say much more

Victor

On 2 May 2012, at 18:11, Michael Gogins  wrote:

> The heap in Csound has always bothered me. We could declare a huge
> array of bytes and just index into that for allocations, reset the
> index to 0 in Reset. That would do wonders for our real-time
> capabilities and our runtime efficiency. This could be an option or,
> perhaps, the default for real-time performance.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I infer that the Faust object uses memory allocated by Csound -- is
that correct? Or is it the other way round?

Regards,
Mike

On Wed, May 2, 2012 at 1:26 PM, Victor  wrote:
> Well, I have encountered difficulties when memory is not allocated dynamically. When I was helping with the Faust Csound arch, one of the first problems I saw was that the opcodes would crash when the Faust object was not created dynamically, because of memory issues. Quickly fixed by tapping into the AuxAlloc mechanism. I did not do an extensive analysis at the time, so I cannot say much more
>
> Victor
>
> On 2 May 2012, at 18:11, Michael Gogins  wrote:
>
>> The heap in Csound has always bothered me. We could declare a huge
>> array of bytes and just index into that for allocations, reset the
>> index to 0 in Reset. That would do wonders for our real-time
>> capabilities and our runtime efficiency. This could be an option or,
>> perhaps, the default for real-time performance.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It does, with AuxAlloc.
Victor


On 2 May 2012, at 18:29, Michael Gogins  wrote:

> I infer that the Faust object uses memory allocated by Csound -- is
> that correct? Or is it the other way round?
> 
> Regards,
> Mike
> 
> On Wed, May 2, 2012 at 1:26 PM, Victor  wrote:
>> Well, I have encountered difficulties when memory is not allocated dynamically. When I was helping with the Faust Csound arch, one of the first problems I saw was that the opcodes would crash when the Faust object was not created dynamically, because of memory issues. Quickly fixed by tapping into the AuxAlloc mechanism. I did not do an extensive analysis at the time, so I cannot say much more
>> 
>> Victor
>> 
>> On 2 May 2012, at 18:11, Michael Gogins  wrote:
>> 
>>> The heap in Csound has always bothered me. We could declare a huge
>>> array of bytes and just index into that for allocations, reset the
>>> index to 0 in Reset. That would do wonders for our real-time
>>> capabilities and our runtime efficiency. This could be an option or,
>>> perhaps, the default for real-time performance.
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> 
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi,

I think this is what supercollider does and it offers both options in
its opcode API. There's a function called RtAlloc and another called
Alloc (or something like that). I haven't looked at the
implementation, but RtAlloc surely uses the mechanism you describe.
Whether it is in the heap or the stack, I am not sure, I haven't
looked.

Cheers,
Andrés

On Wed, May 2, 2012 at 6:11 PM, Michael Gogins  wrote:
> Thanks. I'm trying to figure out how good CLang is as a static code
> analyzer relative to its open source, and proprietary, competition.
>
> One thing I've learned is that in "critical systems" programming
> ("critical" means, a bug can kill you or cause an expensive accident),
> it's common for programmers to use a "modeling system" that generates
> C or C++ code. This would be something like a block diagram designer
> and, in the code generation part of the designer, there would be
> something like a data flow graph of the sort I discussed earlier.
>
> Other interesting things I've learned:
>
> They don't use the heap, they don't use stdio.h, they avoid macros,
> they don't allow pointer arithmetic, and there are many many things in
> Csound code that would not pass. But they are happy with and committed
> to both C and C++ and have pretty much dropped other embedded systems
> programming languages.
>
> The heap in Csound has always bothered me. We could declare a huge
> array of bytes and just index into that for allocations, reset the
> index to 0 in Reset. That would do wonders for our real-time
> capabilities and our runtime efficiency. This could be an option or,
> perhaps, the default for real-time performance.
>
> I found no discussion of threads, which implies that critical systems
> don't use them. Since we do need threads, I will be researching  best
> practices in threaded programming.
>
> I'm going to propose some "Programming Guidelines for Csound" for
> discussion soon, that will cover some of these points.
>
> Regards,
> Mike
>
> On Wed, May 2, 2012 at 12:04 PM, Steven Yi  wrote:
>> XCode has a static analysis option. I run it here and there as it
>> takes a little while to go through, but it brings up some interesting
>> warnings and bugs.  It uses the static analysis tools built in clang.
>> For example, it shows in pmidi.c:
>>
>> Line 228: Array access (from variable 'dev') results in a null pointer
>> dereference
>>
>> If you click for more info, it shows the logic of how it got to that,
>> which is from line 207, if dev == NULL, it can go through that branch
>> of code, then end up proceeding to line 228.
>>
>> With Csound5, I'm currently seeing mostly "Dead Store" messages for
>> variables that are defined but not used. Another example, it found in
>> schedule.c:
>>
>> Line 502: The left operand of '<' is a garbage value
>>
>> If you trace through it, it shows that if on line 460, *p->args[0] ==
>> SSTRCOD, afterwards you proceed through and on line 499, and i <
>> argnum (says "assuming i >= argnum), then the value in line 502 for
>> evt.p[2] can be garbage.
>>
>> csound_orc_parse.c seems to have a number of logic errors of "Function
>> call argument is an uninitialized value".
>>
>> Anyways, I'd say it is particularly useful within XCode as you can
>> trace through visually (it shows arrows between lines of code to
>> illustrate how it got to its analysis).
>>
>> steven
>>
>>
>> On Wed, May 2, 2012 at 2:36 PM, Michael Gogins  wrote:
>>> I've been reading guidelines and coding standards for critical
>>> applications (avionics, motor vehicles, nuclear engineering, space
>>> systems). The consensus of these authors is that coding in C and C++
>>> is suitable for critical embedded systems if a restricted subset of
>>> the language is used and if the code is subjected to thorough testing
>>> and, especially, static analysis.
>>>
>>> My question here is: What, as a Csound developer, is your personal
>>> experience with static analysis tools? Which if any of these tools
>>> have you used? Which would you recommend for use in Csound
>>> development?
>>>
>>> Regards,
>>> Mike
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists

It might be worth having two versions of AuxAlloc, or a flag, to
permit the use of malloc when otherwise a preallocated heap is used.

Regards,
Mike

On Wed, May 2, 2012 at 1:35 PM, Victor  wrote:
> It does, with AuxAlloc.
> Victor
>
>
> On 2 May 2012, at 18:29, Michael Gogins  wrote:
>
>> I infer that the Faust object uses memory allocated by Csound -- is
>> that correct? Or is it the other way round?
>>
>> Regards,
>> Mike
>>
>> On Wed, May 2, 2012 at 1:26 PM, Victor  wrote:
>>> Well, I have encountered difficulties when memory is not allocated dynamically. When I was helping with the Faust Csound arch, one of the first problems I saw was that the opcodes would crash when the Faust object was not created dynamically, because of memory issues. Quickly fixed by tapping into the AuxAlloc mechanism. I did not do an extensive analysis at the time, so I cannot say much more
>>>
>>> Victor
>>>
>>> On 2 May 2012, at 18:11, Michael Gogins  wrote:
>>>
>>>> The heap in Csound has always bothered me. We could declare a huge
>>>> array of bytes and just index into that for allocations, reset the
>>>> index to 0 in Reset. That would do wonders for our real-time
>>>> capabilities and our runtime efficiency. This could be an option or,
>>>> perhaps, the default for real-time performance.
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Michael Gogins wrote:

> My question here is: What, as a Csound developer, is your personal
> experience with static analysis tools? Which if any of these tools
> have you used? Which would you recommend for use in Csound
> development?

My experience a couple of years ago on receiving the Coverity
report on libsndfile:

    http://www.mega-nerd.com/erikd/Blog/CodeHacking/libsndfile/rel_19.html

Basically 68 warnings, split our roughly equally sized groups:

  * False positives.
  * Warnings about header files being included un-necessarily.
  * In test suite code not used in the library itself.
  * Real bugs; resource leaks, dead code, reading beyond the end of
    arrays, off-by-one errors, not handling error return values, bad
    free calls etc.

Valuable tool? Hell yeah (totally ignoring the expense of Coverity of
course). However, existing code bases, especially old code bases like
CSound will require a lot of cleaning up to reduce spurious warnings.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks!

AuxAlloc etc all use memalloc.c which currently uses malloc but does not 
have to.  In earlier times malloc was very inefficient and it was common 
to organise ones own global/heap allocation.  More recent C 
implementations are better so malloc now used

You are free to experiment with this code - I have from time to time

==John ff

Will comment of static analysis later

On Wed, 2 May 2012, Michael Gogins wrote:

> It might be worth having two versions of AuxAlloc, or a flag, to
> permit the use of malloc when otherwise a preallocated heap is used.
>
> Regards,
> Mike
>
> On Wed, May 2, 2012 at 1:35 PM, Victor  wrote:
>> It does, with AuxAlloc.
>> Victor
>>
>>
>> On 2 May 2012, at 18:29, Michael Gogins  wrote:
>>
>>> I infer that the Faust object uses memory allocated by Csound -- is
>>> that correct? Or is it the other way round?
>>>
>>> Regards,
>>> Mike
>>>
>>> On Wed, May 2, 2012 at 1:26 PM, Victor  wrote:
>>>> Well, I have encountered difficulties when memory is not allocated dynamically. When I was helping with the Faust Csound arch, one of the first problems I saw was that the opcodes would crash when the Faust object was not created dynamically, because of memory issues. Quickly fixed by tapping into the AuxAlloc mechanism. I did not do an extensive analysis at the time, so I cannot say much more
>>>>
>>>> Victor
>>>>
>>>> On 2 May 2012, at 18:11, Michael Gogins  wrote:
>>>>
>>>>> The heap in Csound has always bothered me. We could declare a huge
>>>>> array of bytes and just index into that for allocations, reset the
>>>>> index to 0 in Reset. That would do wonders for our real-time
>>>>> capabilities and our runtime efficiency. This could be an option or,
>>>>> perhaps, the default for real-time performance.
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I was wondering how to access the heap (in C) without malloc.

Victor
On 5 May 2012, at 10:08, John ffitch wrote:

> AuxAlloc etc all use memalloc.c which currently uses malloc but does not 
> have to.  In earlier times malloc was very inefficient and it was common 
> to organise ones own global/heap allocation.  More recent C 
> implementations are better so malloc now used
> 
> You are free to experiment with this code - I have from time to time
> 
> ==John ff
> 
> Will comment of static analysis later
> 
> On Wed, 2 May 2012, Michael Gogins wrote:
> 
>> It might be worth having two versions of AuxAlloc, or a flag, to
>> permit the use of malloc when otherwise a preallocated heap is used.
>> 
>> Regards,
>> Mike
>> 
>> On Wed, May 2, 2012 at 1:35 PM, Victor  wrote:
>>> It does, with AuxAlloc.
>>> Victor
>>> 
>>> 
>>> On 2 May 2012, at 18:29, Michael Gogins  wrote:
>>> 
>>>> I infer that the Faust object uses memory allocated by Csound -- is
>>>> that correct? Or is it the other way round?
>>>> 
>>>> Regards,
>>>> Mike
>>>> 
>>>> On Wed, May 2, 2012 at 1:26 PM, Victor  wrote:
>>>>> Well, I have encountered difficulties when memory is not allocated dynamically. When I was helping with the Faust Csound arch, one of the first problems I saw was that the opcodes would crash when the Faust object was not created dynamically, because of memory issues. Quickly fixed by tapping into the AuxAlloc mechanism. I did not do an extensive analysis at the time, so I cannot say much more
>>>>> 
>>>>> Victor
>>>>> 
>>>>> On 2 May 2012, at 18:11, Michael Gogins  wrote:
>>>>> 
>>>>>> The heap in Csound has always bothered me. We could declare a huge
>>>>>> array of bytes and just index into that for allocations, reset the
>>>>>> index to 0 in Reset. That would do wonders for our real-time
>>>>>> capabilities and our runtime efficiency. This could be an option or,
>>>>>> perhaps, the default for real-time performance.
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> 
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> 
>> 
>> -- 
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> 
>> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

In much critical software, the heap is simply not used. The software
declares all storage as static objects.

For Csound that wouldn't work. We would use the heap just once, to
allocate a large array of bytes, then Csound's existing memory
allocation routines would simply bite off a chunk of that as needed.
There would be no deallocation at all. The reset function would simply
set the internal heap's "next allocation" pointer back to the
beginning of the internal heap.

I believe that much commercial audio software does these things
(static objects and simple internal heap) or similar things
(preallocate synthesizer voices).

Regards,
Mike

On Sat, May 5, 2012 at 5:24 AM, Victor Lazzarini
 wrote:
> I was wondering how to access the heap (in C) without malloc.
>
> Victor
> On 5 May 2012, at 10:08, John ffitch wrote:
>
>> AuxAlloc etc all use memalloc.c which currently uses malloc but does not
>> have to.  In earlier times malloc was very inefficient and it was common
>> to organise ones own global/heap allocation.  More recent C
>> implementations are better so malloc now used
>>
>> You are free to experiment with this code - I have from time to time
>>
>> ==John ff
>>
>> Will comment of static analysis later
>>
>> On Wed, 2 May 2012, Michael Gogins wrote:
>>
>>> It might be worth having two versions of AuxAlloc, or a flag, to
>>> permit the use of malloc when otherwise a preallocated heap is used.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Wed, May 2, 2012 at 1:35 PM, Victor  wrote:
>>>> It does, with AuxAlloc.
>>>> Victor
>>>>
>>>>
>>>> On 2 May 2012, at 18:29, Michael Gogins  wrote:
>>>>
>>>>> I infer that the Faust object uses memory allocated by Csound -- is
>>>>> that correct? Or is it the other way round?
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> On Wed, May 2, 2012 at 1:26 PM, Victor  wrote:
>>>>>> Well, I have encountered difficulties when memory is not allocated dynamically. When I was helping with the Faust Csound arch, one of the first problems I saw was that the opcodes would crash when the Faust object was not created dynamically, because of memory issues. Quickly fixed by tapping into the AuxAlloc mechanism. I did not do an extensive analysis at the time, so I cannot say much more
>>>>>>
>>>>>> Victor
>>>>>>
>>>>>> On 2 May 2012, at 18:11, Michael Gogins  wrote:
>>>>>>
>>>>>>> The heap in Csound has always bothered me. We could declare a huge
>>>>>>> array of bytes and just index into that for allocations, reset the
>>>>>>> index to 0 in Reset. That would do wonders for our real-time
>>>>>>> capabilities and our runtime efficiency. This could be an option or,
>>>>>>> perhaps, the default for real-time performance.
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://www.michael-gogins.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 05/05/2012 12:10, Michael Gogins wrote:
> In much critical software, the heap is simply not used. The software
> declares all storage as static objects.
>
> For Csound that wouldn't work. We would use the heap just once, to
> allocate a large array of bytes, then Csound's existing memory
> allocation routines would simply bite off a chunk of that as needed.
> There would be no deallocation at all. The reset function would simply
> set the internal heap's "next allocation" pointer back to the
> beginning of the internal heap.
>
> I believe that much commercial audio software does these things
> (static objects and simple internal heap) or similar things
> (preallocate synthesizer voices).
>

Indeed. Nevertheless, I think we would still need to support a 
small-memory footprint version of Csound, for devices with relatively 
little available. My Raspberry Pi (256MB ram) is due to be delivered by 
the end of this month, and of course Csound is one of the things I would 
want to be able run on it (if that is not already hopelessly 
over-optimistic!). There is no guarantee that relying for example on 
virtual memory (on an SD card) would always be viable for real-time. 
Which makes me think that having such things decided purely internally 
may not give enough flexibility or user control, and that a top-level 
opcode such as "mreserve" (or at the very least a command line flag 
option) might be needed. In the original CDP system running on the Atari 
ST, we used an environment variable to declare how much memory our 
custom allocator would be allowed to use for our "big audio buffer". 
With a machine with 1MB RAM (seemed generous at the time), there were 
any number of processes that could otherwise very easily exceed that.

This also implies that, if at all possible, a pre-perf pass to analyse 
score and orch for memory requirements at least for ftables might be 
useful; and in good old OOP terms, having opcodes/instruments able to 
report in advance how much memory they need could come in handy.  Might 
there be a case for running two distinct memory pools; one for opcodes 
themselves, with small granularity, and another for ftables?

Richard Dobson

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Sat, May 5, 2012 at 7:38 AM, Richard Dobson
 wrote:
>
> On 05/05/2012 12:10, Michael Gogins wrote:
> > In much critical software, the heap is simply not used. The software
> > declares all storage as static objects.
> >
> > For Csound that wouldn't work. We would use the heap just once, to
> > allocate a large array of bytes, then Csound's existing memory
> > allocation routines would simply bite off a chunk of that as needed.
> > There would be no deallocation at all. The reset function would simply
> > set the internal heap's "next allocation" pointer back to the
> > beginning of the internal heap.
> >
> > I believe that much commercial audio software does these things
> > (static objects and simple internal heap) or similar things
> > (preallocate synthesizer voices).
> >
>
> Indeed. Nevertheless, I think we would still need to support a
> small-memory footprint version of Csound, for devices with relatively
> little available. My Raspberry Pi (256MB ram) is due to be delivered by
> the end of this month, and of course Csound is one of the things I would
> want to be able run on it (if that is not already hopelessly
> over-optimistic!). There is no guarantee that relying for example on
> virtual memory (on an SD card) would always be viable for real-time.
> Which makes me think that having such things decided purely internally
> may not give enough flexibility or user control, and that a top-level
> opcode such as "mreserve" (or at the very least a command line flag
> option) might be needed. In the original CDP system running on the Atari
> ST, we used an environment variable to declare how much memory our
> custom allocator would be allowed to use for our "big audio buffer".
> With a machine with 1MB RAM (seemed generous at the time), there were
> any number of processes that could otherwise very easily exceed that.
>
> This also implies that, if at all possible, a pre-perf pass to analyse
> score and orch for memory requirements at least for ftables might be
> useful; and in good old OOP terms, having opcodes/instruments able to
> report in advance how much memory they need could come in handy.  Might
> there be a case for running two distinct memory pools; one for opcodes
> themselves, with small granularity, and another for ftables?


This sounds a bit overengineered to me. I think it is just better to
instruct csound (via a commandline) to preallocate a chunk of heap
available through AuxAlloc. If the memory pool is exhausted, fail and
tell the user to increment the chunk size (much like the java
runtime). If no commandline specified (or non-realtime performance),
just use regular malloc.

Hmm either my google foo is not working today or there are no popular
memory pool implementations in C.


--

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listi

It might be a good idea seeing how supercollider does it.

Cheers,
Andrés

On Sun, May 6, 2012 at 2:26 AM, Felipe Sateler  wrote:
> On Sat, May 5, 2012 at 7:38 AM, Richard Dobson
>  wrote:
>>
>> On 05/05/2012 12:10, Michael Gogins wrote:
>> > In much critical software, the heap is simply not used. The software
>> > declares all storage as static objects.
>> >
>> > For Csound that wouldn't work. We would use the heap just once, to
>> > allocate a large array of bytes, then Csound's existing memory
>> > allocation routines would simply bite off a chunk of that as needed.
>> > There would be no deallocation at all. The reset function would simply
>> > set the internal heap's "next allocation" pointer back to the
>> > beginning of the internal heap.
>> >
>> > I believe that much commercial audio software does these things
>> > (static objects and simple internal heap) or similar things
>> > (preallocate synthesizer voices).
>> >
>>
>> Indeed. Nevertheless, I think we would still need to support a
>> small-memory footprint version of Csound, for devices with relatively
>> little available. My Raspberry Pi (256MB ram) is due to be delivered by
>> the end of this month, and of course Csound is one of the things I would
>> want to be able run on it (if that is not already hopelessly
>> over-optimistic!). There is no guarantee that relying for example on
>> virtual memory (on an SD card) would always be viable for real-time.
>> Which makes me think that having such things decided purely internally
>> may not give enough flexibility or user control, and that a top-level
>> opcode such as "mreserve" (or at the very least a command line flag
>> option) might be needed. In the original CDP system running on the Atari
>> ST, we used an environment variable to declare how much memory our
>> custom allocator would be allowed to use for our "big audio buffer".
>> With a machine with 1MB RAM (seemed generous at the time), there were
>> any number of processes that could otherwise very easily exceed that.
>>
>> This also implies that, if at all possible, a pre-perf pass to analyse
>> score and orch for memory requirements at least for ftables might be
>> useful; and in good old OOP terms, having opcodes/instruments able to
>> report in advance how much memory they need could come in handy.  Might
>> there be a case for running two distinct memory pools; one for opcodes
>> themselves, with small granularity, and another for ftables?
>
>
> This sounds a bit overengineered to me. I think it is just better to
> instruct csound (via a commandline) to preallocate a chunk of heap
> available through AuxAlloc. If the memory pool is exhausted, fail and
> tell the user to increment the chunk size (much like the java
> runtime). If no commandline specified (or non-realtime performance),
> just use regular malloc.
>
> Hmm either my google foo is not working today or there are no popular
> memory pool implementations in C.
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists

On Wed, May 2, 2012 at 9:36 AM, Michael Gogins  wrote:
> My question here is: What, as a Csound developer, is your personal
> experience with static analysis tools? Which if any of these tools
> have you used? Which would you recommend for use in Csound
> development?

Just because I was bored, I ran cppcheck against the csound source
tree. The results are here:

http://people.debian.org/~fsateler/csound-cppcheck/


-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Sun, May 6, 2012 at 4:31 PM, Felipe Sateler  wrote:
> On Wed, May 2, 2012 at 9:36 AM, Michael Gogins  wrote:
>> My question here is: What, as a Csound developer, is your personal
>> experience with static analysis tools? Which if any of these tools
>> have you used? Which would you recommend for use in Csound
>> development?
>
> Just because I was bored, I ran cppcheck against the csound source
> tree. The results are here:
>
> http://people.debian.org/~fsateler/csound-cppcheck/

The clang compiler also has a static analyzer, and I ran it too. The
result is at the link below. The reports include the information
Steven indicated is available in XCode: where is the error, and the
path taken there. Presumably the XCode static analyzer is clang.

http://people.debian.org/~fsateler/csound-clang/

To run it, you need to have clang installed, and then look for the
ccc-analyzer command (in debian, it is under
/usr/share/clang/scan-build). Then invoke cmake with
-DCMAKE_C{,XX}_COMPILER=/path/to/ccc-analyzer, and then do scan-build
-o clang-report make.


-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Felipe,

These two reports you posted are really great to have, thanks!  As for
XCode, yes, it uses clang for static analysis.

One thing that would be nice is if we could make these reports easily
reproducible.  I was thinking a shell script that could call cmake
might be good.  The idea I have is similar to how iOS builds are
setup, so we could have a folder called csound6/staticAnaysis, and
within it have two scripts, one for cppcheck and one for clang.  We
could then have a work folder created for either of them where the
reports are generated and have the work folders in .gitignore.  Sound
good?

Just FYI for everyone, I'm going to be mostly just a passive
participant in Csound dev until after Friday as I have one last
project to complete for my first year studies.  After that I'll be
looking forward to spending a couple days catching up with all the dev
from the past few weeks and getting back into the swing of things.

Thanks!
steven


On Sun, May 6, 2012 at 11:32 PM, Felipe Sateler  wrote:
> On Sun, May 6, 2012 at 4:31 PM, Felipe Sateler  wrote:
>> On Wed, May 2, 2012 at 9:36 AM, Michael Gogins  wrote:
>>> My question here is: What, as a Csound developer, is your personal
>>> experience with static analysis tools? Which if any of these tools
>>> have you used? Which would you recommend for use in Csound
>>> development?
>>
>> Just because I was bored, I ran cppcheck against the csound source
>> tree. The results are here:
>>
>> http://people.debian.org/~fsateler/csound-cppcheck/
>
> The clang compiler also has a static analyzer, and I ran it too. The
> result is at the link below. The reports include the information
> Steven indicated is available in XCode: where is the error, and the
> path taken there. Presumably the XCode static analyzer is clang.
>
> http://people.debian.org/~fsateler/csound-clang/
>
> To run it, you need to have clang installed, and then look for the
> ccc-analyzer command (in debian, it is under
> /usr/share/clang/scan-build). Then invoke cmake with
> -DCMAKE_C{,XX}_COMPILER=/path/to/ccc-analyzer, and then do scan-build
> -o clang-report make.
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net