diff between memmove & memecpy

[ROSY]

ohhh!!! exactly ur plonker to whom???

*plonk*




Brian Rodenborn

 

[Mark McIntyre]

On 28 Sep 2003 20:02:15 -0700, in comp.lang.c ,

again spoking ur nose.

thats "poking your nose". Unless you're planning to turn your nose
into a cartwheel?

 

[Mark McIntyre]

On 28 Sep 2003 20:08:28 -0700, in comp.lang.c ,

r u harlot!!!dont be silly ,ur not at that level atleast.R u meet some plonker
except me????

I've no idea what your native tongue is, but that collection of words
above is utterly meaningless.

So, to everyone else...
_____________________
/| /| | |
||__|| | Please do not |
/ O O\__ | feed the |
/ \ | Trolls |
/ \ \|_____________________|
/ _ \ \ ||
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ | _||
/ / \ |____| ||
/ | | | --|
| | | |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ | ||
/ _ \\ | / `
* / \_ /- | | |
* ___ c_c_c_C/ \C_c_c_c____________

 

[Thomas Matthews]

FYI, the mem*() functions are not string functions. The string
functions are str*(), and work with NULL terminated character
arrays.

Who told you that ?


N869
7.21 String handling <string.h>
7.21.1 String function conventions
[#1] The header <string.h> declares one type and several
functions, and defines one macro useful for manipulating
arrays of character type and other objects treated as arrays
of character type. The type is size_t and the macro is
NULL (both described in 7.17). Various methods are used for
determining the lengths of the arrays, but in all cases a
char * or void * argument points to the initial (lowest
addressed) character of the array. If an array is accessed
beyond the end of an object, the behavior is undefined.

void* arguments have nothing to do with any functions
that start with str*.

I'm not correlating a void * with string functions.
I'm stating that string functions use the NULL character '\0'
for determining the end of the region whereas the mem*()
function use explicit length parameter for the size.

One exception is strncpy, which copies up to a null character
or until the given number of characters is reached.

memcmp() has no side effects, which is part of the reason
that memcmp() does not belong in the same group
of string functions, as those which OP asked about.

In Harbison & Steele, 3rd edition, the authors differentiate
the str*() functions under string processing and the mem*()
functions under memory functions (of which memcmp is also
listed).

To quote the chapter summary of Chapter 14, Memory Functions:
The facilities in this chapter give the C programmer
efficient ways to copy, compare and set blocks of memory.

String functions are functions that operate on NULL terminated
sequences of characters.

When using the str*() functions for manipulating memory,
they will terminate when an char value of 0x00 is
encountered, whereas the mem*() functions won't.

There's always the issue of whether you are trolling or not.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

 

[djinni]

On 28 Sep 2003 20:08:28 -0700, in comp.lang.c ,


I've no idea what your native tongue is, but that collection of words
above is utterly meaningless.

You could try running his gibberish through the program I posted on
Sept. 27'th, though it currently has no support for "d00dsp33k".

-dj

 

[pete]

pete wrote:

Thomas Matthews wrote:


ROSY wrote:



1. How would you use the functions memcpy(),
memset(), memmove()?

There is also memcmp().


Are you out of your MIND !?
OP's question is CLEARLY only about the string functions
which return type pointer to void, and which have side effects.

Anyway, the answer to the question is here:

http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/


FYI, the mem*() functions are not string functions. The string
functions are str*(), and work with NULL terminated character
arrays.

Who told you that ?


N869
7.21 String handling <string.h>
7.21.1 String function conventions
[#1] The header <string.h> declares one type and several
functions, and defines one macro useful for manipulating
arrays of character type and other objects treated as arrays
of character type. The type is size_t and the macro is
NULL (both described in 7.17). Various methods are used for
determining the lengths of the arrays, but in all cases a
char * or void * argument points to the initial (lowest
addressed) character of the array. If an array is accessed
beyond the end of an object, the behavior is undefined.

void* arguments have nothing to do with any functions
that start with str*.

I'm not correlating a void * with string functions.

*The C Standard* correlates a void* with string functions.
That's my point.
The functions which take void* arguments,
are the string functions which start witm "mem".

Harbison & Steele, 3rd edition

Thank you for answering my question.
Harbison & Steele, has no authority.

There's always the issue of whether you are trolling or not.

I'm on topic. Now we have learned
that what Harbison & Steele call "Memory Functions",
are what the C standard calls "String functions".
The C standard lumps the functions which start with "mem",
together with the rest of the string functions.
The big difference between "String function" and "Memory function",
is that "String function" is in the C standard
and "Memory function", isn't.

N869
7.21 String handling <string.h>
7.21.1 String function conventions
7.21.2 Copying functions
7.21.2.1 The memcpy function
7.21.2.2 The memmove function
7.21.2.3 The strcpy function
7.21.2.4 The strncpy function

7.21.4 Comparison functions
7.21.4.1 The memcmp function
7.21.4.2 The strcmp function

As you can see, strcpy and memcpy are both "copying functions"
under section 7.21.2, under section 7.21, which is "String handling"

 

[Slartibartfast]

I find it amazing how a C coder's competence is usually inversely
proportional to his/her usage of "U" and "ur" instead of "you" and
"your". Is it written somewhere in stone or is it just a rule of
thumb?

And how exactly does that differ from other abbreviations that are
commonly used here - such as IMHO, IIRC, AFAIK, HTH, HAND, etc etc??

Oh yes - they irritate you - therefore the user must be a moron.

 

[Grumble]

I personally find it laughable when people spend more time learing

I reckon there's some smart money to be made writing a new language in
d00dsp33k.... just think of all the idiots that would buy your
compiler, just so as to be up with the rest of the lusers.

Is d00dsp33k anything like California codin'?
http://pauillac.inria.fr/~xleroy/stuff/california-prog.html

;-)

 

[carl mcguire]

And how exactly does that differ from other abbreviations that are
commonly used here - such as IMHO, IIRC, AFAIK, HTH, HAND, etc etc??

Oh yes - they irritate you - therefore the user must be a moron.

These aren't abbreviations, they are acronyms.

 

[Slartibartfast]

These aren't abbreviations, they are acronyms.

And an acronym is :

"An identifier formed from some of the letters (often the initials)
of a phrase and used as an abbreviation" - OED.

Note the word "abbreviation".

 

[Andreas Kahari]

And an acronym is :

"An identifier formed from some of the letters (often the initials)
of a phrase and used as an abbreviation" - OED.

Note the word "abbreviation".

Note the word "phrase".

 

[Richard Bos]

And how exactly does that differ from other abbreviations that are
commonly used here - such as IMHO, IIRC, AFAIK, HTH, HAND, etc etc??

They aren't used by complete illiterates simply because they're too lazy
to learn to spell properly - rather, they're used by (often very)
literate netizens to significantly reduce the space taken by
often-recurring phrases with, essentially, the function of social
lubricant.

Oh yes - they irritate you - therefore the user must be a moron.

No, the general quality of the _rest_ of the text, not to mention the
code, if any is even given, convinces us that the user is a moron. Use
of d00dsp33k is merely a very good indicator of said fact.

Richard

 

[Michael Winter]

on 30 Sept 03:

etc??

They aren't used by complete illiterates simply because they're too lazy
to learn to spell properly - rather, they're used by (often very)
literate netizens to significantly reduce the space taken by
often-recurring phrases with, essentially, the function of social
lubricant.

However, they do make posts harder to read. I'm still new to many of
the acronyms used and I spend more time when reading posts that
contain them trying to figure out what they mean than absorbing the
actual content of the message. Memorising those acronyms can almost
be a prerequisite on this group (and others) in some cases, and that's
a problem in my view. Is it really worth using them for the extra one
or two seconds it would take to type those words in full (the same
goes for many abbreviations, namely d00dsp33k)? I don't believe so.
Not only are they irritating, they can greatly hinder non-English
speakers' comprehension.

End of rant.

Mike

 

[Mark McIntyre]

On 30 Sep 2003 02:22:31 -0700, in comp.lang.c ,

And how exactly does that differ from other abbreviations that are
commonly used here - such as IMHO, IIRC, AFAIK, HTH, HAND, etc etc??

The second lot are acronyms for otherwise long and cumbersome phrases.
"u" and "ur" save exactly two bytes each. Wow.

Yes' I've seen your dictionary quote later in the thread. So what?

Oh yes - they irritate you - therefore the user must be a moron.

On the contrary, its an experimental conclusion. A large majority of
those who use SMS-speak or d00dsp33k are also self-evidently lusers.
QED.

 

[Mark McIntyre]

Is d00dsp33k anything like California codin'?

http://pauillac.inria.fr/~xleroy/stuff/california-prog.html

thats pretty funny. And yes..

 

[Slartibartfast]

and if you can't be polite, then you should go away.

That disqualifies half the people here, doesn't it.

 

[Slartibartfast]

The second lot are acronyms for otherwise long and cumbersome phrases.
"u" and "ur" save exactly two bytes each. Wow.

Joona's point, as well you know, had nothing to do with characters saved.

A large majority of those who use SMS-speak or d00dsp33k are also
self-evidently lusers.

Please explain the logic underlying that conclusion. You must be personally
acquainted with every SMS user worldwide.

 

[Joona I Palaste]

<snip>

Joona's point, as well you know, had nothing to do with characters saved.

Please explain the logic underlying that conclusion. You must be personally
acquainted with every SMS user worldwide.

No he's not. But if we constrain his point to:
A large majority of those who use SMS-speak or d00dsp33k *WHEN WRITING
TO COMP.LANG.C* are also self-evidently lusers,
then by empirical research we can show him to be more-or-less right.

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"You can pick your friends, you can pick your nose, but you can't pick your
relatives."
- MAD Magazine

 

[Chris Dollin]

I'm not correlating a void * with string functions.
I'm stating that string functions use the NULL character '\0'

Nitpick: NUL, not NULL. Or just the overloaded `null`.

 

[Dan Pop]

Nitpick: NUL, not NULL. Or just the overloaded `null`.

"null" is much better. To someone who is not familiar with the ASCII
three letter abbreviations, "NUL" looks like a mistyped "NULL".

Dan