Re: memcopy, memmove Implementation
Richard Heathfield <firstname.lastname@example.org> writes:
> Dan Pop wrote:
> > In <email@example.com> Micah Cowan <firstname.lastname@example.org> writes:
> > >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.
|All times are GMT. The time now is 08:25 PM.|
Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.