[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.

-Xuejun

> -----Original Message-----
> From: csmith-dev-bounces@flux.utah.edu
> [mailto:csmith-dev-bounces@flux.utah.edu] On Behalf Of Arthur O'Dwyer
> Sent: Monday, June 20, 2011 12:12 AM
> To: csmith-dev@flux.utah.edu
> Subject: Re: [csmith-dev] feature request: generate memory unsafe code
> 
> On Sun, Jun 19, 2011 at 8:25 AM, Xuejun Yang <jxyang@cs.utah.edu> 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
suggested
> > because the message may interfere with differential testing of
compilers.
> > 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))
>     #else
>      #define MAY_BE_NULL(ptr) (ptr)
>     #endif
> 
>     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
> contexts.
> 
>   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.
> 
> -Arthur