memcpy()

This is a rather stupid question. Sorry bout that.

Its understandable for different docs to say the function has undefined behavior if its src and des overlap...but if they are the same, the behavior isn't actually undefined, just time is wasted and the data in the array just stays the same, right?

But if the standard doesn't say anything about that, is there some wild possibility it could be different on some scary, retarded platform?

{2}rIng

Comments

  • : This is a rather stupid question. Sorry bout that.
    :
    : Its understandable for different docs to say the function has undefined behavior if its src and des overlap...but if they are the same, the behavior isn't actually undefined, just time is wasted and the data in the array just stays the same, right?
    :
    : But if the standard doesn't say anything about that, is there some wild possibility it could be different on some scary, retarded platform?
    :
    : {2}rIng
    :

    I cannot think of any platform that does that, but since it's undefined, it could be implemented in a future platform/implementation.


  • : : This is a rather stupid question. Sorry bout that.
    : :
    : : Its understandable for different docs to say the function has undefined behavior if its src and des overlap...but if they are the same, the behavior isn't actually undefined, just time is wasted and the data in the array just stays the same, right?
    : :
    : : But if the standard doesn't say anything about that, is there some wild possibility it could be different on some scary, retarded platform?
    : :
    : : {2}rIng
    : :
    :
    : I cannot think of any platform that does that, but since it's undefined, it could be implemented in a future platform/implementation.
    :
    :
    :

    All I can think of is that some OS's might wine about read/write on a single memory block at the same time (eg the block is locked).
    If you can avoid it, do so :)

    Best Regards,
    Richard

  • use movemem() if there is a possibility that src and dest can overlap.
  • : : : This is a rather stupid question. Sorry bout that.
    : : :
    : : : Its understandable for different docs to say the function has undefined behavior if its src and des overlap...but if they are the same, the behavior isn't actually undefined, just time is wasted and the data in the array just stays the same, right?
    : : :
    : : : But if the standard doesn't say anything about that, is there some wild possibility it could be different on some scary, retarded platform?
    : : :
    : : : {2}rIng
    : : :
    : :
    : : I cannot think of any platform that does that, but since it's undefined, it could be implemented in a future platform/implementation.
    : :
    : :
    : :
    :
    : All I can think of is that some OS's might wine about read/write on a single memory block at the same time (eg the block is locked).
    : If you can avoid it, do so :)
    :

    But then that platform cannot handle simple code as:
    *(a+1) = *a;
    (if a isn't on the edge of a block)
    And that means that that platform wouldn't be ansi...
  • [b][red]This message was edited by BitByBit_Thor at 2006-12-31 7:45:31[/red][/b][hr]
    :
    : But then that platform cannot handle simple code as:
    : *(a+1) = *a;
    : (if a isn't on the edge of a block)
    : And that means that that platform wouldn't be ansi...
    :

    The two memory blocks here do not overlap. The blocks are of size dependant on what type a is.
    What you are saying here is that the value of the 2nd block becomes the value of the first block, but in no way do the second and the first block overlap.

    Then again, I could be mistaken, since I haven't programmed in C for a while now :P

    EDIT: I see your point though. The platform could still copy then, if it just locks the memory block used by *(a + 0). If it however locks the entire block ('block a') then we have a problem ;)


    Best Regards,
    Richard



  • : [b][red]This message was edited by BitByBit_Thor at 2006-12-31 7:45:31[/red][/b][hr]
    : :
    : : But then that platform cannot handle simple code as:
    : : *(a+1) = *a;
    : : (if a isn't on the edge of a block)
    : : And that means that that platform wouldn't be ansi...
    : :
    :
    : The two memory blocks here do not overlap. The blocks are of size dependant on what type a is.
    : What you are saying here is that the value of the 2nd block becomes the value of the first block, but in no way do the second and the first block overlap.
    :
    : Then again, I could be mistaken, since I haven't programmed in C for a while now :P
    :
    : EDIT: I see your point though. The platform could still copy then, if it just locks the memory block used by *(a + 0). If it however locks the entire block ('block a') then we have a problem ;)
    :
    :
    : Best Regards,
    : Richard
    :
    :
    :

    Sorry I missunderstood...

    In dos blocks are about 512 bytes of memmory, and dos operates almost everywhere with only blocks. If a would be an int, then it would access the same block twice...

    That was my point.
  • :
    : In dos blocks are about 512 bytes of memmory, and dos operates almost everywhere with only blocks. If a would be an int, then it would access the same block twice...
    :
    : That was my point.
    :
    [blue]These are some strange statements... are you talking about disk clusters?[/blue]
  • : :
    : : In dos blocks are about 512 bytes of memmory, and dos operates almost everywhere with only blocks. If a would be an int, then it would access the same block twice...
    : :
    : : That was my point.
    : :
    : [blue]These are some strange statements... are you talking about disk clusters?[/blue]
    :

    DOS layers disc clusters to blocks.
  • : : :
    : : : In dos blocks are about 512 bytes of memmory, and dos operates almost everywhere with only blocks. If a would be an int, then it would access the same block twice...
    : : :
    : : : That was my point.
    : : :
    : : [blue]These are some strange statements... are you talking about disk clusters?[/blue]
    : :
    :
    : DOS layers disc clusters to blocks.
    :
    [blue]That is, probably correct, but when we talk about the memcpy - nothing of the disk is there - just pure memory and it does not have any blocks. CPU has cache, but it does not affect the memcpy() at all.[/blue]
  • : : : :
    : : : : In dos blocks are about 512 bytes of memmory, and dos operates almost everywhere with only blocks. If a would be an int, then it would access the same block twice...
    : : : :
    : : : : That was my point.
    : : : :
    : : : [blue]These are some strange statements... are you talking about disk clusters?[/blue]
    : : :
    : :
    : : DOS layers disc clusters to blocks.
    : :
    : [blue]That is, probably correct, but when we talk about the memcpy - nothing of the disk is there - just pure memory and it does not have any blocks. CPU has cache, but it does not affect the memcpy() at all.[/blue]
    :

    Yeah I know, but there was the misunderstanding. And also, the most efficient way of operating on files should be to buffer a block in memmory to work on, and there you have a block.

    I think I thought of paging, which exist in many processors...
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories