Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #21998

Re: copy size

Show all headers | View raw

David T. Ashley <dashley@gmail.com> writes:

> On Fri, 08 Jun 2012 09:32:34 -0400, Eric Sosman
> <esosman@ieee-dot-org.invalid> wrote:
>
>>> b)Allowing memcpy(dptr, sptr, 0) means that you decided to push logic
>>> to handle the size=0 case down into the function, by definition.  It
>>> could just as easily be handled by the caller.  In some programs, the
>>> case of size=0 and an invalid pointer go together.  It seems useful to
>>> make it standard that if size=0, neither pointer will be dereferenced.
>>
>>     This seems self-contradictory.  If the caller can handle a
>>special case "just as easily," why is it "useful" to require the
>>internals of memcpy() to handle it in a particular way?
>
> Please don't play Devil's Advocate because you are bored  : ).
>
> Creating a memcpy() function that doesn't handle the size=0 case is
> just as silly as creating a square root function that calculates
> square root for every non-negative integer except 0.  [snip]

I think you're confusing implementation and specification.

I expect most implementations will work just fine for any pointer
values given to memcpy() when the number of bytes to be moved is
zero.

However, the specification is written considering all possible
implementations, including some that have hardware characteristics
we don't even know about yet.  In light of that, it is natural to
give as much freedom as we can to implementors of library
functions like memcpy(), provided the burden on developers using
those functions isn't too high.  Here the burden seems pretty low
-- in practice I expect most calls to memcpy() either are known to
have valid pointer arguments, or are inside an if() if the pointer
arguments might not be valid (and so the calls would not be made
if the pointer arguments were null, for example), ie, the tests
would be made anyway, independent of whether memcpy() always works
for zero length calls.  Since the burden seems to be low, we give
implementations more latitude, because even though _most_ won't
need it, _some_ may find it a significant benefit.  It's because
we don't know the characteristics of all implementations,
including future implementations, that it makes sense to keep
the specifications as unrestrictive as we reasonably can.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

copy size sinbad <sinbad.sinbad@gmail.com> - 2012-06-07 22:16 -0700
  Re: copy size Keith Thompson <kst-u@mib.org> - 2012-06-07 22:40 -0700
    Re: copy size David T. Ashley <dashley@gmail.com> - 2012-06-08 09:15 -0400
      Re: copy size Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-08 09:32 -0400
        Re: copy size David T. Ashley <dashley@gmail.com> - 2012-06-08 09:40 -0400
          Re: copy size Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-08 10:31 -0400
          Re: copy size Keith Thompson <kst-u@mib.org> - 2012-06-08 11:53 -0700
          Re: copy size Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-08 12:11 -0700
            Re: copy size "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-06-08 12:32 -0700
              Re: copy size Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-08 20:42 -0700
      Re: copy size pete <pfiland@mindspring.com> - 2012-06-08 10:30 -0400
      Re: copy size Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-08 11:47 -0700
    Re: copy size pete <pfiland@mindspring.com> - 2012-06-08 10:05 -0400

csiph-web