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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#43750

On 2014-04-28, Geoff <geoff@invalid.invalid> wrote:
> On Mon, 28 Apr 2014 17:07:31 -0400, "Bill Cunningham"
>>memcpy(a,b,sizeof(a+b));
> WTF!---------------^^^

Material this good can only come from having great staff.

Kudos to the talented writers behind "Late Night with Bill Cunningham"!

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

#43762

Le 28/04/2014 23:55, Kaz Kylheku a écrit :
> On 2014-04-28, Geoff <geoff@invalid.invalid> wrote:
>> On Mon, 28 Apr 2014 17:07:31 -0400, "Bill Cunningham"
>>> memcpy(a,b,sizeof(a+b));
>> WTF!---------------^^^
>
> Material this good can only come from having great staff.
>
> Kudos to the talented writers behind "Late Night with Bill Cunningham"!
>
+1 !!!!!!!

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

#43759

Geoff <geoff@invalid.invalid> writes:

> On Mon, 28 Apr 2014 17:07:31 -0400, "Bill Cunningham"
> <nospam@nspam.invalid> wrote:
>
>>
>>"Geoff" <geoff@invalid.invalid> wrote in message 
>>news:p4ftl9p41bj9nktk2b71lqfgbeuq2jseg0@4ax.com...
>>
>>[...]
>>
>>> memcpy is somewhat more safe. Memcpy doesn't manipulate C strings,
>>> only bytes, it knows nothing of zero termination it copies without
>>> judgement of the content it's copying. It takes three arguments, a
>>> destination, a source and a length. As long as length is <= the size
>>> of destination the copy will only copy the number of bytes that
>>> destination is expected to hold. Of course, you can still create
>>> problems for yourself if the source and destinations overlap or if you
>>> use a length greater than the destination.
>>
>>char *a="String one";
>>char *b="String two";
>>
>>memcpy(a,b,sizeof(a+b));
> WTF!---------------^^^
>
> That is wrong on two levels:
> 1. You don't SUM two lengths to get the destination length.
> 2. You don't SUM two pointers to get the length of anything.
>
>>
>>Is that a "strcpy" like representation? Atleast to an extent.
>>
> No, it's not even close.
> If you are going to use strings explicitly then use strcpy.

LOL! You're not serious are you?

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

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

#43747

On 2014-04-28, Bill Cunningham <nospam@nspam.invalid> wrote:
>
> "Geoff" <geoff@invalid.invalid> wrote in message 
> news:p4ftl9p41bj9nktk2b71lqfgbeuq2jseg0@4ax.com...
>
> [...]
>
>> memcpy is somewhat more safe. Memcpy doesn't manipulate C strings,
>> only bytes, it knows nothing of zero termination it copies without
>> judgement of the content it's copying. It takes three arguments, a
>> destination, a source and a length. As long as length is <= the size
>> of destination the copy will only copy the number of bytes that
>> destination is expected to hold. Of course, you can still create
>> problems for yourself if the source and destinations overlap or if you
>> use a length greater than the destination.
>
> char *a="String one";
> char *b="String two";
>
> memcpy(a,b,sizeof(a+b));
>
> Is that a "strcpy" like representation? Atleast to an extent.

* Bill Cunningham: An important member (holding the rank of inspector) of an unspecified, quite
  possibly fictional secret service force (possibly based upon the British Secret Intelligence
  Service). His most prominent bodily feature is his half-bald head. He meets the children upon
  their very first adventure and makes regular appearances in the series from that point on. Mostly
  the children get tangled up in adventures which are connected with Bill's work at the time and end
  up solving them for him.
  Following the events in The Ship of Adventure, Bill marries Mrs Mannering and adopts all the
  children as his own. Upon first encountering the children, he used the alias "Bill Smugs" - a name
  which appeared again in The Mountain of Adventure.

https://en.wikipedia.org/wiki/Adventure_Series

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

#43758

"Bill Cunningham" <nospam@nspam.invalid> writes:

> "Geoff" <geoff@invalid.invalid> wrote in message 
> news:p4ftl9p41bj9nktk2b71lqfgbeuq2jseg0@4ax.com...
>
> [...]
>
>> memcpy is somewhat more safe. Memcpy doesn't manipulate C strings,
>> only bytes, it knows nothing of zero termination it copies without
>> judgement of the content it's copying. It takes three arguments, a
>> destination, a source and a length. As long as length is <= the size
>> of destination the copy will only copy the number of bytes that
>> destination is expected to hold. Of course, you can still create
>> problems for yourself if the source and destinations overlap or if you
>> use a length greater than the destination.
>
> char *a="String one";
> char *b="String two";
>
> memcpy(a,b,sizeof(a+b));
>
> Is that a "strcpy" like representation? Atleast to an extent.
>

LOL!

11/10


-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

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

#43767

On Mon, 28 Apr 2014 17:07:31 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

<snip quoted text from a different author> 

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

-- 
Remove del for email

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

#43781

"Barry Schwarz" <schwarzb@dqel.com> wrote in message 
news:khmtl9ddoebrkgllr42g952umesh5j5845@4ax.com...
> 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.

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

#43733

Geoff <geoff@invalid.invalid> writes:

> On Mon, 28 Apr 2014 16:25:27 -0400, "Bill Cunningham"
> <nospam@nspam.invalid> wrote:
>
>>    Is there a specific reason for using strcpy and memcpy for different 
>>uses? They look to me like the same thing.
>
> They are quite different.
>
> As the name implies, strcpy expects a valid C string in the source
> argument. A C string is a string of non-zero characters terminated by
> a zero character. If it's not a valid C string it will copy
> everything, including data you don't expect, up to the first zero
> char, into the destination. This can overflow your destination,
> leading to unexpected and unintended behavior in your program.

It can also read beyond the valid bounds of the source.

> memcpy is somewhat more safe. Memcpy doesn't manipulate C strings,
> only bytes, it knows nothing of zero termination it copies without
> judgement of the content it's copying. It takes three arguments, a
> destination, a source and a length. As long as length is <= the size
> of destination the copy will only copy the number of bytes that
> destination is expected to hold. Of course, you can still create
> problems for yourself if the source and destinations overlap or if you
> use a length greater than the destination.

...or greater than the source.

I'm not sure you can say one is any safer (or less safe) than the other.

-- 
Ben.

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

#43736

"Bill Cunningham" <nospam@nspam.invalid> writes:
>     Is there a specific reason for using strcpy and memcpy for different 
> uses? They look to me like the same thing.

They're not.  RTFM.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#43742

"Keith Thompson" <kst-u@mib.org> wrote in message

> They're not.  RTFM.

    I will.

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

#43745

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lneh0hp2xb.fsf@nuthaus.mib.org...
> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>     Is there a specific reason for using strcpy and memcpy for different
>> uses? They look to me like the same thing.
>
> They're not.  RTFM.

    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.

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

#43769

On Mon, 28 Apr 2014 17:44:14 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

<snip quoted text from a different author>

>    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?

-- 
Remove del for email

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

#43773

On 2014-04-28, Barry Schwarz <schwarzb@dqel.com> wrote:
> On Mon, 28 Apr 2014 17:44:14 -0400, "Bill Cunningham"
><nospam@nspam.invalid> wrote:
>
><snip quoted text from a different author>
>
>>    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?

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.

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

#43775

"Kaz Kylheku" <kaz@kylheku.com> wrote in message 
news:20140428155656.233@kylheku.com...
> On 2014-04-28, Barry Schwarz <schwarzb@dqel.com> wrote:
>> On Mon, 28 Apr 2014 17:44:14 -0400, "Bill Cunningham"
>><nospam@nspam.invalid> wrote:
>>
>><snip quoted text from a different author>
>>
>>>    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?
>
> 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.

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

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

#43776

>> 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?

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

#43788

"Bill Cunningham" <nospam@nspam.invalid> wrote in message 
news:ljmo3v$8k5$1@dont-email.me...
>>> 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?

    Oh yes. A genetic fallacy.

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

#43847

"Kaz Kylheku" <kaz@kylheku.com> wrote in message 
news:20140428155656.233@kylheku.com...
> On 2014-04-28, Barry Schwarz <schwarzb@dqel.com> wrote:
>> On Mon, 28 Apr 2014 17:44:14 -0400, "Bill Cunningham"
>><nospam@nspam.invalid> wrote:
>>
>><snip quoted text from a different author>
>>
>>>    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?
>
> 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.

. 

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

#43764

On Mon, 28 Apr 2014 16:25:27 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>    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?

-- 
Remove del for email

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

#43771

"Barry Schwarz" <schwarzb@dqel.com> wrote in message 
news:32ltl91k136t6kosf4bkd7vtrjef0kjhuu@4ax.com...
> 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.
>
> 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?

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

#43783

"Bill Cunningham" <nospam@nspam.invalid> wrote in message 
news:ljmnho$5j6$1@dont-email.me...
>
> "Barry Schwarz" <schwarzb@dqel.com> wrote in message 
> news:32ltl91k136t6kosf4bkd7vtrjef0kjhuu@4ax.com...
>> 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.
>>
>> 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?

    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.

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

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

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

csiph-web