Path: csiph.com!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!mit.eternal-september.org!.POSTED!not-for-mail From: Richard Newsgroups: comp.lang.c Subject: Re: cpy functions Date: Tue, 29 Apr 2014 12:59:45 +0200 Organization: http://www.ieee.org/ Lines: 88 Message-ID: <87k3a8765a.fsf@gmail.com> References: <5943eaaa-c59b-48b1-bd73-6391dfb40f5d@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mit.eternal-september.org; posting-host="a0e0bcceb01a4703df7b4a89dec2423c"; logging-data="6442"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/rXhsVu3W5RnK3I7JqsoBCucBTO9EZUEI=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:tyRqJ1xwMFEAM6pEg1Q+EzXYxbk= sha1:h4eB/yf6SndE0NxXv6qK2PEoDOA= Xref: csiph.com comp.lang.c:43810 Michael Angelo Ravera 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