On Mon, Apr 4, 2011 at 12:43 AM, Werner LEMBERG <[email protected]> wrote:
>> This basically dereferences an (almost) null pointer. Possibly, >> this crashes neatly in debug mode (I'm not sure). The SCM_CDR() >> variant will surely crash with segmentation fault. > > There is a misunderstanding. I was rather talking about Scheme code > entered by the user. The above is a programming error, isn't it? Yes and no. If a user passes '() (ie. SCM_EOL), into a variable which then is interpreted by the C++ code as a pair, then we get a crash. >> * unsmob_grob(x)->foo() >> >> If x is not a grob, unsmob_grob(x) returns NULL. Boom. > > This looks like a programming error too... > > I don't understand why you think that such situations shouldn't be > fixed in the source code. I think it is good that these are fixed, but not important enough to spend serious time on finding and plugging all of them. The question is how much of the code we should consider user-serviceable. If one C++ part of Lily passes data using Scheme types to another C++ part, should that other part be resistent users inserting bogus values into that internal channel ? -- Han-Wen Nienhuys - [email protected] - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
