cpy functions

[Barry Schwarz]

Is there a specific reason for using strcpy and memcpy for different
uses? They look to me like the same thing.

Since you have already stated you never use either one, the best
advice is don't start using them now. You haven't needed them in the
10+ years you have been learning C so don't rock the boat.

Since you have already stated you have not looked at the descriptions
of either, on what do you base your assertion that they look the same?

 

[jacob navia]

Le 29/04/2014 00:17, Bill Cunningham a écrit :

I'm not a C programmer. Just a wannabe and that's because the *nix system
interface is in C. Otherwise C++ would probably be much simpler.

11/10 Bill!

Of course C++ is simpler than C. Go spam comp.lang.c++, it is right
around the corner, and it has much more people to spam than this one.

 

[Barry Schwarz]

On Mon, 28 Apr 2014 17:07:31 -0400, "Bill Cunningham"

char *a="String one";
char *b="String two";

memcpy(a,b,sizeof(a+b));

Is that a "strcpy" like representation? Atleast to an extent.

Depends on the extent. If you are willing to ignore the constraint
violation, the incorrect length, and the undefined behavior, then yes.

 

[Barry Schwarz]

On Mon, 28 Apr 2014 17:22:29 -0400, "Bill Cunningham"

Sorry about my bad code. I am saying a "C String" *is* a bytestream. void*
can take the char * and You can manipulate that 3rd parameter and use use
memcpy. For example.

strtol (a,NULL,10)

is essentially
atoi(a)

excepting aoti doesn't return error code. So we need strtol. And you can

Don't you think it matters that atoi returns an int while strtol
returns a long?

course convert to all but some of the str in strtol.

strtol (a,b,10);

Sorry, I cannot make any sense of this.

 

[Barry Schwarz]

On Mon, 28 Apr 2014 17:44:14 -0400, "Bill Cunningham"

With memcpy, I think it would be the job of the kernel to make sure the
memory areas don't overlap. That's what memory management services are for.

Where in the description of memcpy that you have not read do you see
any reference to a kernel? Which kernel service do you think memcpy
needs to invoke? Why do you think memcpy has anything to do with
memory management?

 

[Bill Cunningham]

Since you have already stated you never use either one, the best
advice is don't start using them now. You haven't needed them in the
10+ years you have been learning C

What makes you think I have been learning or should I say using C for 10+
years? I don't have anything to program except certain interfaces and that's
my main goal with C. I have no practical use to look into these functions at
this time.

so don't rock the boat.

 

[Kaz Kylheku]

On Mon, 28 Apr 2014 17:44:14 -0400, "Bill Cunningham"



Where in the description of memcpy that you have not read do you see
any reference to a kernel?

That's just another coded Cunniham sentence which says "I don't actually have a
spectacular learning disability".

It's silly, but in a way that can only be intelligently contrived, with just
the right dash of plausibility.

You just have to pay attention and "read between the lines".

Which kernel service do you think memcpy
needs to invoke? Why do you think memcpy has anything to do with
memory management?

It's not as crazy as you might think. Typically when we have an API
wich manages, say, "widgets", it lets us create widgets, destroy them,
copy one to another and so on. It's all part of the "management of widgets".

Okay, so, copying of memory is part of the management of memory; memcpy is an
API operation on memory! Get it? malloc creates it, memcpy copies it, etc.

The main point of importance here is that a genuine moron wouldn't make this
up.

Which kernel service might memcpy invoke? One which gives the program the
benefit of, say, a DMA-capable bus master to do the copy, if that is
advantageous for the given parameters.

 

[Bill Cunningham]

That's just another coded Cunniham sentence which says "I don't actually
have a
spectacular learning disability".

It's silly, but in a way that can only be intelligently contrived, with
just
the right dash of plausibility.

You just have to pay attention and "read between the lines".


It's not as crazy as you might think. Typically when we have an API
wich manages, say, "widgets", it lets us create widgets, destroy them,
copy one to another and so on. It's all part of the "management of
widgets".

Okay, so, copying of memory is part of the management of memory; memcpy is
an
API operation on memory! Get it? malloc creates it, memcpy copies it, etc.

The main point of importance here is that a genuine moron wouldn't make
this
up.

Which kernel service might memcpy invoke? One which gives the program the
benefit of, say, a DMA-capable bus master to do the copy, if that is
advantageous for the given parameters.

I have much, much more on my plate than C. It's on and off.

 

[Bill Cunningham]

You just have to pay attention and "read between the lines".

You should be a detective. And you could stay up all day and night
worrying about usenet posts. What Rational Philosophic line of reasoning is
this coming from?

 

[Bill Cunningham]

Of course C++ is simpler than C. Go spam comp.lang.c++, it is right around
the corner, and it has much more people to spam than this one.

And what would you do without me? Come on. I'm such a regular poster...
You would remember me if I didn't post for 2 years. You need me!

 

[Bill Cunningham]

Depends on the extent. If you are willing to ignore the constraint
violation, the incorrect length, and the undefined behavior, then yes.

I don't know what a constraint violation is. I will have to check n1570.

 

[Ian Collins]

And what would you do without me? Come on. I'm such a regular poster...
You would remember me if I didn't post for 2 years. You need me!

Bill the traffic generator?

 

[Bill Cunningham]

What makes you think I have been learning or should I say using C for 10+
years? I don't have anything to program except certain interfaces and
that's my main goal with C. I have no practical use to look into these
functions at this time.

so don't rock the boat.

Not studying the *full* extent of the man pages but looking at the
definition and parameters. You make sense as to not rock the boat.

 

[Bill Cunningham]

You should be a detective. And you could stay up all day and night
worrying about usenet posts. What Rational Philosophic line of reasoning
is this coming from?

Oh yes. A genetic fallacy.

 

[Michael Angelo Ravera]

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, NULterminated", "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 mostother 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 asmall 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".

 

[Ben Bacarisse]

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>

 

[Bill Cunningham]

Sorry, I cannot make any sense of this.

This is certainly deserving of a response. I have never used strtol like
this. I have always used NULL as that second parameter. But I know the 2d
parameter takes an "end pointer" which must be a char **. My example is
probably sad. As I say I've never used an end pointer. Remember to I am
*not* a C programmer. Just an amateur and have other things to do than be on
usenet constantly watching clc or anything else. There are alot of seasoned
programmers around here.
But my understanding of strtol. That b would be a char ** though. To my
understanding as an amateur.

So much for struct addrinfo right now.

Bill

 

[Bill Cunningham]

That's just another coded Cunniham sentence which says "I don't actually
have a
spectacular learning disability".

It's silly, but in a way that can only be intelligently contrived, with
just
the right dash of plausibility.

You just have to pay attention and "read between the lines".

You don't seem to be able to reason correctly. You're conclusions are
genetic non-sequiturs. I'm not stupid. The problem isn't intelligence or
cognizance, as much as aspects of connation and definately affectivity.

..