Re: memcopy, memmove Implementation
 

Richard Heathfield <binary@eton.powernet.co.uk> writes:

> Dan Pop wrote:
> >
> > In <m3adc9xuts.fsf@localhost.localdomain> Micah Cowan <micah@cowan.name> writes:
> >
>
> <snip>
>
> > >An implementation could do anything it likes to stop you, or
> > >not stop you, from violating the const restriction. It is not merely a
> > >reminder to the programmer, but a hint to the compiler (or whatever)
> > >as well.
> >
> > It's a useless hint to the compiler: you can still use the pointer to
> > alter the object value (after casting away the const) and the behaviour
> > is well defined if the original object was not const qualified.
>
> A minor nit: that is incorrect if the original object is a string
> literal, since they are not const-qualified and yet modifying them
> invokes undefined behaviour.

Hm... I think Dan's point is that the const in the parameter decls is
a compiler hint. This may have been pete's point as well. I had
thought he was saying this about "const" in general (but then, I
walked in mid-thread...).

You could just as easily pass a string through a non-const char*
parameter, and modifying it would be just as undefined.

-Micah