[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [csmith-dev] feature request: generate memory unsafe code
Thanks Arthur. That's an easy way to add comma operator. Yes Csmith can
distinguish definite null/dangling pointer dereference from possible
null/dangling pointer deference. That's the benefit of having an analyzer
insider a generator.
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of Arthur O'Dwyer
> Sent: Monday, June 20, 2011 12:12 AM
> To: email@example.com
> Subject: Re: [csmith-dev] feature request: generate memory unsafe code
> On Sun, Jun 19, 2011 at 8:25 AM, Xuejun Yang <firstname.lastname@example.org> wrote:
> [Pascal Cuoq wrote:]
> >> This is great. I have one question: does Csmith know,
> >> when emitting a possible NULL/dangling access,
> >> that it is emitting one, or only that it may be emitting one?
> >> In the former case, it could provide some sort of oracle,
> >> for instance:
> >> p = NULL;
> >> a = 3;
> >> printf("When this line is reached, it is followed by a NULL
> > dereference.\n");
> >> b = *p;
> >> There are ramifications to this issue [...]
> > Yes, Csmith knows when there is a potential null/dangling pointer
> > dereference. But I hesitated to print a runtime message like you
> > because the message may interfere with differential testing of
> > Instead I could print a comment in the random program right above the
> > violating statement, what do you think?
> I think macros are helpful, in this context.
> #if INSTRUMENT
> #define MAY_BE_NULL(ptr) (puts("possible NULL dereference"), (ptr))
> #define MAY_BE_NULL(ptr) (ptr)
> p = NULL;
> a = 3;
> b = *MAY_BE_NULL(p);
> That is, whenever we have a variable v_999 that is a possibly-null
> pointer, Csmith should print it as "MAY_BE_NULL(v_999)" in rvalue
> The above paragraph may want some adjustment if Csmith can actually
> distinguish "possibly-null" pointers from "definitely-null" pointers.
> Dereferencing a pointer that is only *possibly* null is not
> necessarily a bug.