Coding Standards again
Locked
12
12
Coding Standards again
 
|
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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
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 <[hidden email]> 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 > [hidden email] > 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Coding Standards again
|
|
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 <[hidden email]> 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 <[hidden email]> 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 >> [hidden email] >> 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 > [hidden email] > 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Coding Standards again
|
And on the security side, there's Alex Sotirov's vulncheck
(http://gcc.vulncheck.org/). On 5/2/12, Michael Gogins <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> >> 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 >>> [hidden email] >>> 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 >> [hidden email] >> 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 > [hidden email] > 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Coding Standards again
|
In reply to this post by Michael Gogins-2
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 <[hidden email]> 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Coding Standards again
|
|
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 <[hidden email]> 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 <[hidden email]> 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 > [hidden email] > 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Coding Standards again
|
|
It does, with AuxAlloc.
Victor On 2 May 2012, at 18:29, Michael Gogins <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 >> [hidden email] >> 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 > [hidden email] > 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Coding Standards again
|
In reply to this post by Michael Gogins-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 >>> [hidden email] >>> 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 >> [hidden email] >> 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 > [hidden email] > 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Coding Standards again
|
|
In reply to this post by Victor Lazzarini
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 <[hidden email]> wrote: > It does, with AuxAlloc. > Victor > > > On 2 May 2012, at 18:29, Michael Gogins <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 >>> [hidden email] >>> 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 >> [hidden email] >> 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 > [hidden email] > 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Coding Standards again
|
In reply to this post by Michael Gogins-2
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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Coding Standards again
|
|
Thanks! On May 3, 2012 1:17 AM, "Erik de Castro Lopo" <[hidden email]> wrote:
Michael Gogins wrote: ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Coding Standards again
|
In reply to this post by Michael Gogins-2
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 <[hidden email]> wrote: >> It does, with AuxAlloc. >> Victor >> >> >> On 2 May 2012, at 18:29, Michael Gogins <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 >>>> [hidden email] >>>> 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 >>> [hidden email] >>> 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 >> [hidden email] >> 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 > [hidden email] > 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Coding Standards again
|
|
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 <[hidden email]> wrote: >>> It does, with AuxAlloc. >>> Victor >>> >>> >>> On 2 May 2012, at 18:29, Michael Gogins <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 >>>>> [hidden email] >>>>> 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 >>>> [hidden email] >>>> 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 >>> [hidden email] >>> 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 >> [hidden email] >> 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 > [hidden email] > 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Coding Standards again
|
|
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 <[hidden email]> 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 <[hidden email]> wrote: >>>> It does, with AuxAlloc. >>>> Victor >>>> >>>> >>>> On 2 May 2012, at 18:29, Michael Gogins <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 >>>>>> [hidden email] >>>>>> 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 >>>>> [hidden email] >>>>> 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 >>>> [hidden email] >>>> 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 >>> [hidden email] >>> 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 >> [hidden email] >> 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 > [hidden email] > 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Coding Standards again
|
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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Coding Standards again
|
On Sat, May 5, 2012 at 7:38 AM, Richard Dobson
<[hidden email]> 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Coding Standards again
|
|
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 <[hidden email]> wrote: > On Sat, May 5, 2012 at 7:38 AM, Richard Dobson > <[hidden email]> 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 > [hidden email] > 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Coding Standards again
|
|
In reply to this post by Michael Gogins-2
On Wed, May 2, 2012 at 9:36 AM, Michael Gogins <[hidden email]> 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Coding Standards again
|
|
On Sun, May 6, 2012 at 4:31 PM, Felipe Sateler <[hidden email]> wrote:
> On Wed, May 2, 2012 at 9:36 AM, Michael Gogins <[hidden email]> 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Coding Standards again
|
In reply to this post by Felipe Sateler
> http://people.debian.org/~fsateler/csound-cppcheck/
Thanks, I'll help to fix the problems. tito ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
«
Return to Csound - Dev
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |