Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Richard <rgrdev_@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: cpy functions |
| Date | 2014-04-29 12:59 +0200 |
| Organization | http://www.ieee.org/ |
| Message-ID | <87k3a8765a.fsf@gmail.com> (permalink) |
| References | <ljmdfj$su4$1@dont-email.me> <5943eaaa-c59b-48b1-bd73-6391dfb40f5d@googlegroups.com> |
Michael Angelo Ravera <maravera@prodigy.net> writes:
> On Monday, April 28, 2014 1:25:27 PM UTC-7, Bill Cunningham wrote:
>> Is there a specific reason for using strcpy and memcpy for different uses? They look to me like the same thing.
>
> Do us all a favor and learn about Data Representation. None of the
> interfaces will make any sense until you understand Data
> Representation.
> strcpy () is designed to be used on entities that are represented by a
> variable length series of contiguous bytes which end with a NUL
> character ('\0').
"variable length series of contiguous bytes which end with a character"?
There is no "variable length" relevant to the strcpy operation. Unknown
or "unnecessary" length maybe. They are of a fixed length. Delimited by
the eos or "NUL character". Or in context, the fixed length string's
length is NOT determined or required prior to calling the function -
unlike memcpy. This is NOT "variable length" - in the same way that
memcpy blocks are not.
strcpy is designed to copy a string. How it does it is down to the
implementation. But yes the eos is the NUL.
2) bytes?!?!? Whats a byte? a byte != a char. Some people here think a
byte is 3 bits. That's how clever they are!
>
> memcpy () is designed to be used on entities which are represented by a series
> of contiguous bytes of known length (and which might include NUL
> characters). These include structs, arrays of structs, arrays of scalars, or any
> combination. They could even include a group of variable length entities that
> are NUL terminated provided you know the total length.
>
> If you will notice, there is also a function strncpy () whose
> parameters look to be exactly the same as memcpy, but memcpy () and
> strncpy () do very different things (known size vs. variable with a
> limit).
As well as using different types.... So in the words of CLC - nothing
like each other....
>
> So, until you understand how the data are represented, none of these
> functions
In the same way you think a char is a byte?
http://stackoverflow.com/questions/1592737/difference-between-byte-and-char-in-c
Sorry.
When lecturing Bill you'll need to make it a lot simpler.
> is particularly useful, but these functions are used all of the time, even if
> you spend most of your life working with other interfaces. There is more that
> one way to represent what in other languages might be called a string.
> A few of them are "fixed size, (usually blank) padded", "variable size, NUL
> terminated", "variable size, NUL terminated with a limit", and "variable size,
> possibly with a limit, with an external size". You would probably use memcpy ()
> for the first and last representations, strcpy () for the second, and strncpy ()
> with the third. The thing to keep in mind, is that, in most other languages, all
> of these functions would be done with assignment or MOVE statements. In C, you
> have to manage your own representations. These functions give a little help in
> copying one entity represented in one of these ways to another place where that
> entity can be represented.
>
> I have used other data representations and have had to create copying functions
> for them [most of them use combinations of memcpy (), strcpy (), stncpy (), and
> memset()]. For instance, a string with a length prefix (called an "MCW") that,
> if the prefix is a positive is the length of the string, if a small negative
> number it is the number of copies of one byte, and, if a large negative number
> was one of a number of strings from a defined list (which were, of course, MCW
> prefixed). Copying an MCWString to another MCWString or to the end of a growing
> block was a snap (and you could even know, in advance, if you needed to flush
> the block before during or after you added). Copying from a block to an
> MCWString in an optimal fashion was decidely non-trivial, but once created,
> anybody with access to the library could use BlockToMCWString ().
>
> It's all really easy once you understand Data Representationn. It's IMPOSSIBLE until then. What does that suggest to you, Dave? I mean "Bill".
>
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
cpy functions "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-28 16:25 -0400
Re: cpy functions John Gordon <gordon@panix.com> - 2014-04-28 20:42 +0000
Re: cpy functions "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-28 16:54 -0400
Re: cpy functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 22:22 +0100
Re: cpy functions "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-28 17:26 -0400
Re: cpy functions Richard <rgrdev_@gmail.com> - 2014-04-29 00:19 +0200
Re: cpy functions Andrew Smallshaw <andrews@sdf.lonestar.org> - 2014-04-28 20:44 +0000
Re: cpy functions Keith Thompson <kst-u@mib.org> - 2014-04-28 14:44 -0700
Re: cpy functions Geoff <geoff@invalid.invalid> - 2014-04-28 13:55 -0700
Re: cpy functions "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-28 17:07 -0400
Re: cpy functions Geoff <geoff@invalid.invalid> - 2014-04-28 14:13 -0700
Re: cpy functions "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-28 17:22 -0400
Re: cpy functions "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-28 17:32 -0400
Re: cpy functions "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-28 18:17 -0400
Re: cpy functions jacob navia <jacob@spamsink.net> - 2014-04-29 00:43 +0200
Re: cpy functions "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-28 19:31 -0400
Re: cpy functions Ian Collins <ian-news@hotmail.com> - 2014-04-29 11:33 +1200
Re: cpy functions Richard <rgrdev_@gmail.com> - 2014-04-29 02:27 +0200
Re: cpy functions Barry Schwarz <schwarzb@dqel.com> - 2014-04-28 15:53 -0700
Re: cpy functions "Bill Cunningham" <nosapm@nspam.invalid> - 2014-04-29 17:27 -0400
Re: cpy functions Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 21:55 +0000
Re: cpy functions jacob navia <jacob@spamsink.net> - 2014-04-29 00:40 +0200
Re: cpy functions Richard <rgrdev_@gmail.com> - 2014-04-29 00:20 +0200
Re: cpy functions Ike Naar <ike@iceland.freeshell.org> - 2014-04-28 21:48 +0000
Re: cpy functions Richard <rgrdev_@gmail.com> - 2014-04-29 00:20 +0200
Re: cpy functions Barry Schwarz <schwarzb@dqel.com> - 2014-04-28 15:49 -0700
Re: cpy functions "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-28 19:33 -0400
Re: cpy functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 22:13 +0100
Re: cpy functions Keith Thompson <kst-u@mib.org> - 2014-04-28 14:19 -0700
Re: cpy functions "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-28 17:34 -0400
Re: cpy functions "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-28 17:44 -0400
Re: cpy functions Barry Schwarz <schwarzb@dqel.com> - 2014-04-28 15:55 -0700
Re: cpy functions Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 23:19 +0000
Re: cpy functions "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-28 19:24 -0400
Re: cpy functions "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-28 19:26 -0400
Re: cpy functions "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-28 20:07 -0400
Re: cpy functions "Bill Cunningham" <nosapm@nspam.invalid> - 2014-04-29 17:30 -0400
Re: cpy functions Barry Schwarz <schwarzb@dqel.com> - 2014-04-28 15:43 -0700
Re: cpy functions "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-28 19:17 -0400
Re: cpy functions "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-28 19:35 -0400
Re: cpy functions Michael Angelo Ravera <maravera@prodigy.net> - 2014-04-29 03:07 -0700
Re: cpy functions Richard <rgrdev_@gmail.com> - 2014-04-29 12:59 +0200
Re: cpy functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-29 13:58 +0100
csiph-web