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


Groups > comp.lang.c > #21994

Re: copy size

From Keith Thompson <kst-u@mib.org>
Newsgroups comp.lang.c
Subject Re: copy size
Date 2012-06-08 11:53 -0700
Organization None to speak of
Message-ID <lnaa0dd499.fsf@nuthaus.mib.org> (permalink)
References <03c3ed4d-f3ce-437b-9476-1c512c7772de@o3g2000pby.googlegroups.com> <lnehpqcqe3.fsf@nuthaus.mib.org> <o5u3t7t3os1rvojjgtihk67bmhnlt5eqc7@4ax.com> <jqsutq$2hn$1@dont-email.me> <m104t7hdkrifgikal6mo9a1n6lphpb60of@4ax.com>

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.

sqrt() computes square roots; sqrt(0.0) computes the square root of
0.0. It's not a special case.

memcpy() copies memory; memcpy() with size=0 doesn't copy any memory.

And as Eric points out, the standard already requires support for
memcpy() with size=0 if the s1 and s2 arguments are valid.  If they're
not valid, the behavior is undefined, but I don't see that that's a
significant problem.

> It forces the users to either a)wrap the function or b)handle the
> exception case many times whereas handling it in the function would
> require handling it only once.

The only reason to wrap the function or handle exceptional cases is if
you have a call to memcpy() where it's possible to have size=0 *and* one
or more null pointer or otherwise invalid arguments.  I don't see that
happening much in real life.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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