Re: [csmith-dev] feature request: generate memory unsafe code

["Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>]

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