How to realize the function ?

[yezi]

Hi: all:

is some mem cat function with is like "strcat" ?

Thanks

 

[Skarmander]

Hi: all:

is some mem cat function with is like "strcat" ?

No. You can realloc() one memory region, then memcpy() the other at the end;
or just malloc() a new one and copy both. You must know the size of both
regions, obviously.

S.

 

[Richard Bos]

is some mem cat function with is like "strcat" ?

No, and there cannot be. Consider: how does strcat() know where the
first string ends? How would a hypothetical memcat() do the same? (Hint:
it cannot.)

Richard

 

[Niklas Norrthon]

Hi: all:

is some mem cat function with is like "strcat" ?

Not in the sense that it appends one region of memory to
another, since there is no way to know where a memory
region ends. But if you know how large your regions are
you could just use memcpy or memmove from <string.h>

If is quite trivial to implement strcat in terms of strlen
to get the sizes, and memcpy to append. I don't know what
you want to accomplish, but you could take this code as
a starting point:

(Original strcat is probably more efficient, since it doesn't
have to iterate through the src string twice).

#include <string.h>

char*
my_strcat(char* dest, char* src)
{
size_t sz_d = strlen(dest);
size_t sz_s = strlen(src) + 1; /* including '\0' */

memcpy(dest + sz_d, src, sz_s);
return dest;
}

/Niklas Norrthon

 

[Suman]

No, and there cannot be. Consider: how does strcat() know where the
first string ends? How would a hypothetical memcat() do the same? (Hint:
it cannot.)

Then, we shouldn't have memcmp either ?

 

[Richard Bos]

Then, we shouldn't have memcmp either ?

memcmp() doesn't have to figure out for itself where its data ends. You
tell it. You _could_ write a memcat() that you also tell yourself where
its first data block ends. It would be rather pointless, though:

void *memcat(void *dest, void *src, size_t at, size_t len)
{
memcpy(dest+at, src, len);
}

Richard

 

[Suman]

[ replying to the OP]

memcmp() doesn't have to figure out for itself where its data ends. You
tell it. You _could_ write a memcat() that you also tell yourself where
its first data block ends. It would be rather pointless, though:

Correct. To me, the strcat/memcat comparison was a poor one.

void *memcat(void *dest, void *src, size_t at, size_t len)
{

I felt free to drop a:
return

 

[Richard Bos]

[ replying to the OP]

memcmp() doesn't have to figure out for itself where its data ends. You
tell it. You _could_ write a memcat() that you also tell yourself where
its first data block ends. It would be rather pointless, though:

Correct. To me, the strcat/memcat comparison was a poor one.

I agree, but that's what the OP wanted: a function that does for the
mem*() functions what strcat() does for str*(). Since that comparison
does indeed not work, the answer is: there isn't one.

I felt free to drop a:
return

Er... yes... sorry.


Richard

 

[Rudolf]

No, and there cannot be. Consider: how does strcat() know where the
first string ends? How would a hypothetical memcat() do the same? (Hint:
it cannot.)

Since functions like free() and realloc() know how big a memory region
is, then why can't the hypothetical memcat() know how big it is?

 

[Keith Thompson]

Since functions like free() and realloc() know how big a memory region
is, then why can't the hypothetical memcat() know how big it is?

Not really. The existing mem* functions work on arbitrary blocks of
memory, which could be allocated in any of several ways (stack, heap,
global). Whatever hidden information exists for malloc()ed objects
doesn't apply to the others.

If the hypothetical memcat() applied only to malloc()ed objects, it
could work, but then it probably shouldn't have name starting with
"mem".

I haven't seen a rigorous description in this thread of just what
memcat() is supposed to do.

 

[Richard Heathfield]

Keith Thompson said:

I haven't seen a rigorous description in this thread of just what
memcat() is supposed to do.

Presumably it would copy an arbitrary amount of memory to the end of another
arbitrary amount of memory.

#define mem_cat(dst, dstlen, src, srclen) \
memcpy((dst)+(dstlen), src, srclen)

I'm still trying to work out what all the fuss is about.

 

[Niklas Norrthon]

Since functions like free() and realloc() know how big a memory region
is, then why can't the hypothetical memcat() know how big it is?

What would be the semanics of the following program with your
suggested memcat?

#inlcude <stdlib.h>
#include <memcat_header.h> /* whatever that is */

#define BUF_SZ 100
int static_buffer[BUF_SZ];
int* static_ptr;

int main(void)
{
int automatic_buffer[BUF_SZ];
int* automatic_ptr;
int* free_store_ptr = malloc(BUF_SZ * sizeof *free_store_ptr);
/* check for malloc failure */

for (i = 0; i < sizeof static_buffer; ++i) {
static_buffer = i;
automatic_buffer = i;
free_store_ptr = i;
}

static_ptr = static_buffer + BUF_SZ / 2;
automatic_ptr = automatic_buffer + BUF_SZ / 2;

/*
* In the following calls to memcat:
* how much memory would be copied,
* and where would the destiantion be?
* Explain that, and I'll tell you why
* memcat as your proposal can't exist
*/

memcat(static_ptr, automatic_buffer);
memcat(automatic_ptr, static_ptr);
memcat(free_store_ptr, automatic_ptr);

/* and so on, with every possible combination... */
return EXIT_FAILURE;
}

/Niklas Norrthon