The absence of restrict causes some optimizations to be avoided, it 
doesn't cause the compiler to put pointers where it shouldn't.
If a bad thing happens, then it's a bug without or without restrict.
For instance, if the kernel code writes at random places when we call 
accept(fd, &name, &namelen), then it's just a bug.

madhvesh wrote:

> Hi,
> 
> I need one info.
> While using the compiler keyword for pointer arguments as "restrict" for
> function arguments,
> within the library(libc) the code has to ensure that, it doesnot fiddle with
> local
> pointers (as aliases) for these argument pointers. But if the same argument
> is passed
> to system-call which internally passes to kernel-source code, then the
> kernel
> code also has to ensure that, the restrict pointer arguments passed should
> not
> be assigned to local or global varibales within the kernel?
> 
> Does this mean, the kernel should also worry for "restrict" argument
> pointers
> when passed from application program to library to kernel?
>