0

I've got a school project where I have to recode the memccpy() function.

I use 2 programs to check if my code works properly. The first is a small program with only a main. The second program is developped by another student (can be found here, if you want to see it)

With my program, there is no problem, both my memccpy and the original function return the right pointer on the right character from the dest pointer. But with the second program, the original function return a lower pointer adress than the dest pointer starting adress, for example:

  • Starting address of the src value: 0x7fff712edc40
  • Memccpy return pointer address: 0x712edc44
  • My memccpy function return pointer: 0x7fff712edc44

So, as someone compile on his computer and my code return the right adress, it must come from the second program.

Does somebody know what can cause this kind of behavior?

  • I tried to search on Google but the answer was not very helpful.
  • I read the man multiple times ^^' (not more helpful).
  • I read that memccpy have an undefined behavior when memory overlap, but they don't overlap.

Here is my ft_memccpy() function:

void    *ft_memccpy(void *str_dest, const void *str_src, int c, size_t n)
{
    unsigned int    i;
    char            *dest;
    char            *src;
    char            *ptr;

    dest = (char *)str_dest;
    src = (char *)str_src;
    i = 0;
    ptr = 0;
    while (i < n && ptr == 0)
    {
        dest[i] = src[i];
        if (src[i] == ((char)c))
            ptr = dest + i + 1;
        i++;
    }
    return (ptr);
}

Edit: I edited because i got downvote and many user didn't understood my question. So i thought that it was not clear enough, i hope this edit will ^^'.

Olivier
  • 95
  • 2
  • 11
  • What return value are you expecting? – Oliver Charlesworth Jun 27 '15 at 22:26
  • i'm expecting a pointer to the next character in dest after the first 'i' – Olivier Jun 27 '15 at 22:29
  • I am not able to replicate the problem. Both `p1` and `p2` pointers are identical. Can you post complete compilable code demonstrating the issue? – void_ptr Jun 27 '15 at 22:35
  • Please show your `printf` calls. Would like to what format specifier you are using and where the calls are being made. – kaylum Jun 27 '15 at 22:35
  • 1
    Oliver, your issue isn't in `ft_memccpy` (or it's not apparent from your example). Both compile and return the same address. I used the following `printf` call instead `printf ("\n p1 : %p\n p2 : %p\n\n", (char *)p1, (char *)p2);` – David C. Rankin Jun 27 '15 at 22:56
  • The example has to be _minimal_, yet complete and verifiable. It is not reasonable to expect anyone to debug your actual project. What you posted is a bunch of snippets that have to be stitched together, with more code added (e.g. includes). Yet they do not replicate the issue. – void_ptr Jun 27 '15 at 22:58
  • That's not what i'm asking void_ptr. I just posted the whole project because you asked. I'm just asking what can cause this kind of behavior. – Olivier Jun 27 '15 at 23:00
  • @OlivierCosquer - I did not ask for a complete project; I asked for MCVE. Answering your question, the code you posted behaves correctly. It prints equal pointers. – void_ptr Jun 27 '15 at 23:04
  • Notice that the lower 32bits value are the same for the two returned pointer value. So, it was probably the 64bit vs 32 bit pointer problem. – Eric Tsui Jun 27 '15 at 23:27

1 Answers1

0

That's probably the problem of the 64bit pointer and 32bit pointer.

Your ft_memccpy would return a 64 bit pointer, so it outputs

0x7fff712edc44

While the system memccpy returned a 32bit's

0x712edc44
Eric Tsui
  • 1,924
  • 12
  • 21