On Wed, Nov 17, 2010 at 08:08:00PM -0500, Fulko Hew wrote:
> On Wed, Nov 17, 2010 at 4:26 PM, Jeff Spaleta <jspaleta@xxxxxxxxx> wrote:
>
> > On Wed, Nov 17, 2010 at 8:16 PM, Jon Masters <jonathan@xxxxxxxxxxxxxx>
> > wrote:
> > > Did anyone upstream look into a compatibility environment variable that
> > > could be exported to change the direction of the memcpy? Yes, it's a
> > > hack, but it would allow affected users to have an option.
> >
> > Could we make use of that sort of environment variable feature more
> > generally as a way to build environments that test for bad memcpy
> > usage similar to this by flipflopping back and forth, even while we
> > are writing code?
> >
>
> Its been a few decades since I last had to write a memcpy, but the last time
> I did,
> I made sure it worked with overlapping regions and just 'did the right
> thing'
> and made it as optimized as possible (for the CPUs available).
>
> I know the definition for memcpy (on Linux) says don't use overlapping
> regions but thats really a poor excuse for knowingly misbehaving when
> it could certainly prevented. Sorry, but using 'optimization' as a defense
> is just plain poor engineering practices.
>
> Its certainly easier to provide a single well-behaved memcpy than it is to
> ensure that ALL programmers in the world write software that prevents
> overlapping regions.
>
> It may just be me, but wouldn't it be 'common sense'?
Do all of your screwdrivers have big bulky ends so you can hammer nails in with
them? memcpy was given a specific purpose so it could be optimized for it. It
was a design choice in the spec itself, made when it was given its name. That's
why there's memmove. A program that uses functions outside of spec is still
broken, even if it happens to work, just like it is if it reads an
uninitialized variable but still works because the uninitialized space happens
to contain zero whenever the function is called.
This is why I gave up on Objective C. The two features of the language I wanted
(better memory management and exceptions) were ruined by silly gotchas in the
documentation. The memory management documentation essentially forbade you
directly from trying to understand memory management conceptually ("Don't think
of it as refcounting. Think of it as us telling you where to put these little
bits of code and you doing it and then your memory management works.")[1] and
the exceptions just came with a big warning label that said "try not to
actually use these if you can help it." I know for a fact both of these things
would have worked fine for me in the practical implementation, but they were
specified wrong so I left the language alone. Common sense is malleable, the
only thing anyone's held accountable for is the documentation and that's how it
has to be.
--CJD
[1] C itself is in a similar situation with its specification of pointers. We
all think of memory as an array of bytes and of pointers as an integer index
into that array, but if you think of C pointers that way and try to actually
read the bits in them you will break the spec, even though your program will
likely work. Its a good example here since if this were 1975 I could actually
find the compiler and CPU architecture that would, due to absolute necessity,
break your program. Hell if they're function pointers I just need a PPC box.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
