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

["Xuejun Yang" <jxyang@cs.utah.edu>]

Hi Pascal,

Nice thoughts. See my reply below.
 
> 
> 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: with the above instrumentation,
> a NULL access only happens after a function call. That seriously limits
> the generality of generated programs.
> 
> Anyway, there is always the possibility of comparing several
> tools, for which instrumentation is not necessary.

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 am adding array OOB soon.
> 
> For OOB, one potential issue for comparing tools
> is that a tool would be justified in warning
> at the computation of the invalid pointer
> (except if it's only one past) whereas other tools
> may only warn when/if the invalid pointer is
> dereferenced. When comparing tools of these
> two categories,this means warnings in different
> places when the pointer is dereferenced,
> and warning against no warning if it isn't.
> 
> Similarly, one tool may allow out-of-bound
> accesses to members of struct/unions and elements of
> arrays as long as the memory access, computed with
> the target platform size/alignment parameters, fall inside
> a larger object that contains the first one. I mean that
> it may allow:
> 
> int t[10][10];
> struct { int a; int b; } s;
> 
> main(){
> t[0][12] == t[1][2];
> (&s.a)[1] == s.b;
> return 0;
> }
> 
> A tool such as Valgrind, working on object code, would
> probably only be able to offer this behavior anyway.
> 

Csmith doesn't support pointer arithmetic right now. All possible OOB
accesses are strictly array index OOB. For your example " t[0][12] =
t[1][2]" is allowed by Csmith. We may support things like "(&s.a)[1] = s.b"
when we add pointer arithmetic in the future.

-Xuejun