«

Hi all,

is it possible to write a function named memcat, which offers
functionality similar to that of the strcat fn, i.e i mean a function
on the following lines:-

void * memcat(void *s1, void *s2);

now s1 should point to the beginning of the concatenated memory
region. now as in strcat how to determine the terminating memory
location...???

wrote:
> Hi all,
>
> is it possible to write a function named memcat, which offers
> functionality similar to that of the strcat fn, i.e i mean a function
> on the following lines:-
>
> void * memcat(void *s1, void *s2);

You need to define the functionality you expect from such a function.

> now s1 should point to the beginning of the concatenated memory
> region. now as in strcat how to determine the terminating memory
> location...???

That, as the man said so memorably, is the question.

wrote:
> Hi all,
>
> is it possible to write a function named memcat, which offers
> functionality similar to that of the strcat fn, i.e i mean a function
> on the following lines:-
>
> void * memcat(void *s1, void *s2);
>
> now s1 should point to the beginning of the concatenated memory
> region. now as in strcat how to determine the terminating memory
> location...???

Let's begin with the last question: How to determine
the end. Two ends, really, because you need to find the
end of the existing piece that begins at s1 and the end
of the added piece that begins at s2. The other memxxx
function (memset, memchr, ...) use byte counts for this:
the caller provides an extra argument giving the number
of bytes in the memory area. For memcat there are two
memory areas, hence two counts, and the function looks like

void *memcat(void *s1, size_t n1, void *s2, size_t n2);

Let's not stop there, though. Think for a minute about
what memcat will do, internally. All the area 1 bytes will
remain as they are, untouched, and the new material will be
added right after them. So memcat probably begins with

void *target = (char*)s1 + n1;

.... to get a pointer the the spot where the new material
will go. (The (char*) cast is needed because you can't do
arithmetic on a void* pointer.) What next? The rest of the
job is just copying the area 2 material to its new position.
So the complete implementation of memcat might look like

void *memcat(void *s1, size_t n1, void *s2, size_t n2) {
void *target = (char*)s1 + n1;
memcpy(target, s2, n2);
return s1;
}

.... or, with some abbreviation
void *memcat(void *s1, size_t n1, void *s2, size_t n2) {
memcpy((char*)s1 + n1, s2, n2);
return s1;
}

(An "industrial-strength" version would probably use const
on s2, and a version for C99 compilers would also use the
restrict qualifier, but the outline would be the same.)

In other words, memcat is just memcpy with a different
starting point! And that's probably why it doesn't exist in
the Standard library: it's a trivial variation on a function
that's already provided. Adding it would be a little bit like
adding a sqrt_half function that computed the square root of
one-half its argument: A task that's easily done by calling
the usual sqrt function with a halved argument to begin with.

--
Eric Sosman
lid

On Fri, 23 Nov 2007 09:10:52 -0500,
Eric Sosman <> wrote:
> wrote:
>> Hi all,
>>
>> is it possible to write a function named memcat, which offers
>> functionality similar to that of the strcat fn, i.e i mean a function
>> on the following lines:-
>>
>> void * memcat(void *s1, void *s2);
>>
>> now s1 should point to the beginning of the concatenated memory
>> region. now as in strcat how to determine the terminating memory
>> location...???

[snip]
>
> void *memcat(void *s1, size_t n1, void *s2, size_t n2) {
> memcpy((char*)s1 + n1, s2, n2);
> return s1;
> }

of course, if you wrote it like this, you'd have to include string.h, in
which case you shouldn't be naming your function memcat()i as long as it
has external linkage, as that would be a reserved identifier.

Martien
--
|
Martien Verbruggen | Computers in the future may weigh no more
| than 1.5 tons. -- Popular Mechanics, 1949
|

On Sat, 24 Nov 2007 08:43:57 +1100, Martien Verbruggen wrote:
> On Fri, 23 Nov 2007 09:10:52 -0500,
> Eric Sosman <> wrote:
>>
>> void *memcat(void *s1, size_t n1, void *s2, size_t n2) {
>> memcpy((char*)s1 + n1, s2, n2);
>> return s1;
>> }
>
> of course, if you wrote it like this, you'd have to include string.h, in
> which case you shouldn't be naming your function memcat()i as long as it
> has external linkage, as that would be a reserved identifier.

memcat is a reserved external name even if you don't include string.h.
Including string.h means that you're also not allowed to define static
void *memcat(...), or typedef void memcat, since it becomes reserved as a
file scope identifier.

wrote:
>
> is it possible to write a function named memcat, which offers
> functionality similar to that of the strcat fn, i.e i mean a
> function on the following lines:-
>
> void * memcat(void *s1, void *s2);
>
> now s1 should point to the beginning of the concatenated memory
> region. now as in strcat how to determine the terminating memory
> location...???

Strings are terminated by the final '\0'. Memory blocks have no
such delimiter. Thus you have to have, and supply, the sizes of
the memory blocks. Therefore the prototype could be:

int memcat(char *s1, size_t sz1, /* input block & destination
*/
char *s2, size_t sz2, /* block to add to it */
size_t szout); /* maximum size of *s1 */

and it can return an error indicator, such as non-zero for failure
to fit everything.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

On Nov 23, 4:43 pm, Martien Verbruggen <m...@tradingpost.com.au>
wrote:
> On Fri, 23 Nov 2007 09:10:52 -0500,
> Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>
> > aark...@gmail.com wrote:
> >> Hi all,
>
> >> is it possible to write a function named memcat, which offers
> >> functionality similar to that of the strcat fn, i.e i mean a function
> >> on the following lines:-
>
> >> void * memcat(void *s1, void *s2);
>
> >> now s1 should point to the beginning of the concatenated memory
> >> region. now as in strcat how to determine the terminating memory
> >> location...???
>
> [snip]
>
>
>
> > void *memcat(void *s1, size_t n1, void *s2, size_t n2) {
> > memcpy((char*)s1 + n1, s2, n2);
> > return s1;
> > }
>
> of course, if you wrote it like this, you'd have to include string.h, in
> which case you shouldn't be naming your function memcat()i as long as it
> has external linkage, as that would be a reserved identifier.
>
> Martien
> --
> |
> Martien Verbruggen | Computers in the future may weigh no more
> | than 1.5 tons. -- Popular Mechanics, 1949
> |

I searched my /usr/include/string.h file for memcat but i didn't find
any. I use gcc v 4.01

wrote, On 24/11/07 04:13:
> On Nov 23, 4:43 pm, Martien Verbruggen <m...@tradingpost.com.au>
> wrote:

<snip>

>> of course, if you wrote it like this, you'd have to include string.h, in
>> which case you shouldn't be naming your function memcat()i as long as it
>> has external linkage, as that would be a reserved identifier.
>>
>> Martien
>> --
>> |
>> Martien Verbruggen | Computers in the future may weigh no more
>> | than 1.5 tons. -- Popular Mechanics, 1949
>> |

Please don't quote peoples signatures, the bit typically after the "-- "
or anything else not relevant to your reply.

> I searched my /usr/include/string.h file for memcat but i didn't find
> any. I use gcc v 4.01

Martien did not say it was defined, he said it was reserved. I.e. you
are *not* allowed to use that name whether it is currently used or not.
The GNU people could decide to use it in the next minor release thus
breaking your code, or they might be using some "compiler magic" which
well break your code, or they could perfectly legally just detect that
you have used it and deliberately generate code that generates random
insults.
--
Flash Gordon

On Fri, 23 Nov 2007 20:13:33 -0800 (PST), wrote:

>On Nov 23, 4:43 pm, Martien Verbruggen <m...@tradingpost.com.au>
>wrote:

snip

>> of course, if you wrote it like this, you'd have to include string.h, in
>> which case you shouldn't be naming your function memcat()i as long as it
>> has external linkage, as that would be a reserved identifier.
>>
>> Martien
>> --
>> |
>> Martien Verbruggen | Computers in the future may weigh no more
>> | than 1.5 tons. -- Popular Mechanics, 1949
>> |
>
>I searched my /usr/include/string.h file for memcat but i didn't find
>any. I use gcc v 4.01

Which only proves that your system doesn't have it.

The real issue is that the name is reserved, regardless of whether it
is in use at the moment or not.


Remove del for email

On Nov 23, 9:10 am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> aark...@gmail.com wrote:
> > Hi all,
>
> > is it possible to write a function named memcat, which offers
> > functionality similar to that of the strcat fn, i.e i mean a function
> > on the following lines:-
>
> > void * memcat(void *s1, void *s2);
>
> > now s1 should point to the beginning of the concatenated memory
> > region. now as in strcat how to determine the terminating memory
> > location...???
>
> Let's begin with the last question: How to determine
> the end. Two ends, really, because you need to find the
> end of the existing piece that begins at s1 and the end
> of the added piece that begins at s2. The other memxxx
> function (memset, memchr, ...) use byte counts for this:
> the caller provides an extra argument giving the number
> of bytes in the memory area. For memcat there are two
> memory areas, hence two counts, and the function looks like
>
> void *memcat(void *s1, size_t n1, void *s2, size_t n2);
>
> Let's not stop there, though. Think for a minute about
> what memcat will do, internally. All the area 1 bytes will
> remain as they are, untouched, and the new material will be
> added right after them. So memcat probably begins with
>
> void *target = (char*)s1 + n1;
>
> ... to get a pointer the the spot where the new material
> will go. (The (char*) cast is needed because you can't do
> arithmetic on a void* pointer.) What next? The rest of the
> job is just copying the area 2 material to its new position.
> So the complete implementation of memcat might look like
>
> void *memcat(void *s1, size_t n1, void *s2, size_t n2) {
> void *target = (char*)s1 + n1;
> memcpy(target, s2, n2);
> return s1;
> }
>
> ... or, with some abbreviation
> void *memcat(void *s1, size_t n1, void *s2, size_t n2) {
> memcpy((char*)s1 + n1, s2, n2);
> return s1;
> }
>
> (An "industrial-strength" version would probably use const
> on s2, and a version for C99 compilers would also use the
> restrict qualifier, but the outline would be the same.)
>
> In other words, memcat is just memcpy with a different
> starting point! And that's probably why it doesn't exist in
> the Standard library: it's a trivial variation on a function
> that's already provided. Adding it would be a little bit like
> adding a sqrt_half function that computed the square root of
> one-half its argument: A task that's easily done by calling
> the usual sqrt function with a halved argument to begin with.

I tried your function as follows:-

#include<stdio.h>
#include<stdlib.h>
#include<string.h>

void *mcat(void *s1, size_t n1, void *s2, size_t n2)
{
int k;
void *target = (char*)s1 + n1;
memcpy(target,s2, n2);

return s1;
}

int main(void)
{

int i =2,j=3,k;
int *p,*q,*r;

p = &i; q = &j;
r = mcat(p,sizeof(int),q,sizeof(int));

for(k=0;k<2;k++)
printf("\t %d",r[k]);
puts("");
return(EXIT_SUCCESS);
}

29,1
but getting the o/p as 2 1 instead of 2 3