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

Groups > comp.lang.c > #43723 > unrolled thread

cpy functions

Back to article view | Back to comp.lang.c

Contents

  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

Page 3 of 3 — ← Prev page 1 2 [3]

#43809

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').

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).

So, until you understand how the data are represented, none of these functions 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".

[toc] | [prev] | [next] | [standalone]

#43810

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

[toc] | [prev] | [next] | [standalone]

#43819

Richard <rgrdev_@gmail.com> writes:
<snip>
> 2) bytes?!?!?

Was there supposed to be a 1)?

> Whats a byte?

It's an addressable unit of storage, large enough to hold a character.
You probably know that, but your plan here is to suggest that properly
understanding C requires believing in all sorts of wacky things, so I
think it helps to put the record straight.

> a byte != a char.

Yes, one is a unit of storage and the other is a type so, they are not
identical concepts.  However a 'char' is always one byte in size.

On some word-addressed hardware (now largely defunct, I think) the
smallest hardware addressable unit was larger than the minimum required
8 bits.  The C standard is written so as to allow several different ways
of implementing C on such systems, but I'm sure you are not interested
in that.

> Some people here think a
> byte is 3 bits.

That may be true, but I don't recall anyone saying so.  Let's hope you
will be on hand to correct them should they ever be so foolish!

<snip>
-- 
Ben.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web