It looks to me like this problem was eliminated by a fairly extensive
rewrite to use C++ String objects in portsmf. If I read the report
correctly, the bug could be demonstrated by trying to load a 2000
character file consisting of repeated 0x41 ("AAAAAA...") as a .gro file.
I did this in my working copy of Audacity with the portsmf library,
traced some of the code, and found that the parser was passing around
strings of length 2000, printed a reasonable error message:
AAAAAAAAAAAAAA... [many lines to print "A" 2000 times)
^ Unexpected character in pitch
and did not crash. I can't claim there are therefore NO bugs, but it
looks like this particular bug is no longer with us.
I forgot who complained about string handling in portsmf or why, but
I remember it was in connection with Audacity, so probably someone
reading this, and that was why I spent the time to redo the code using
String instead of fixed-length buffers. So to whoever it was: good call!
-Roger
Richard Ash wrote:
> By complete chance I found this:
>
http://secunia.com/advisories/33356/>
> which is a flaw in allegro. Obviously because we replaced it in audacity
> with portsmf we don't directly have it any more, but the portsmf code
> should also be checked for the same issue.
>
> Richard
>
>
>
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
