malloc(allocator) aligned by 8 or 16 byte

Discussion in 'C Programming' started by shaanxxx, Sep 12, 2007.

  1. shaanxxx

    shaanxxx Guest

    why malloc (allocator) guarantees that address return by them will be
    aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?
     
    shaanxxx, Sep 12, 2007
    #1
    1. Advertising

  2. shaanxxx

    Ian Collins Guest

    shaanxxx wrote:
    > why malloc (allocator) guarantees that address return by them will be
    > aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?
    >

    It doesn't. It guarantees the address is suitably aligned for any type.
    This has to be the case because malloc returns a void* which can be
    assigned to any pointer type.

    --
    Ian Collins.
     
    Ian Collins, Sep 12, 2007
    #2
    1. Advertising

  3. shaanxxx said:

    > why malloc (allocator) guarantees that address return by them will be
    > aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?


    The C language standard makes no such guarantee.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Sep 12, 2007
    #3
  4. In article <>,
    shaanxxx <> wrote:
    >why malloc (allocator) guarantees that address return by them will be
    >aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?


    Presumably on those systems there are objects that have to be aligned
    on 8- or 16- byte boundaries. For example, it's quite likely that a
    double is 8 bytes long and has to be 8-byte aligned. Even if it
    doesn't *have* to be aligned, it may be more efficient if it is.
    This varies from system to system - you can't rely on it.

    Since malloc() doesn't know what kind of object you're going to store
    in the memory, it has to make sure it's aligned for any kind (or at
    least, any kind that will fit).

    I can't guess what type it is on the 64-bit machine that requires
    16-byte alignment.

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, Sep 12, 2007
    #4
  5. shaanxxx <> writes:

    > why malloc (allocator) guarantees that address return by them will be
    > aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?


    IIRC malloc() (on success) is guaranteed to return address that is
    aligned so that any object can be stored correctly. Why it is exactly 8
    or 16 bytes you should check in your compiler's documentation.

    --
    Best regards, _ _
    .o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
    ..o | Computer Science, Michal "mina86" Nazarewicz (o o)
    ooo +--<mina86*tlen.pl>---<jid:mina86*chrome.pl>--ooO--(_)--Ooo--
     
    Michal Nazarewicz, Sep 12, 2007
    #5
  6. shaanxxx

    shaanxxx Guest

    On Sep 12, 4:03 pm, Ian Collins <> wrote:
    > shaanxxx wrote:
    > > why malloc (allocator) guarantees that address return by them will be
    > > aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?

    >
    > It doesn't. It guarantees the address is suitably aligned for any type.
    > This has to be the case because malloc returns a void* which can be
    > assigned to any pointer type.
    >
    > --
    > Ian Collins.


    http://g.oswego.edu/dl/html/malloc.html

    if you read this document, you will find that author is little keen
    about keeping alignment at eight byte.
     
    shaanxxx, Sep 12, 2007
    #6
  7. "Richard Tobin" <> a écrit dans le message de news:
    fc8hql$24ri$...
    > In article <>,
    > shaanxxx <> wrote:
    >>why malloc (allocator) guarantees that address return by them will be
    >>aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?

    >
    > Presumably on those systems there are objects that have to be aligned
    > on 8- or 16- byte boundaries. For example, it's quite likely that a
    > double is 8 bytes long and has to be 8-byte aligned. Even if it
    > doesn't *have* to be aligned, it may be more efficient if it is.
    > This varies from system to system - you can't rely on it.
    >
    > Since malloc() doesn't know what kind of object you're going to store
    > in the memory, it has to make sure it's aligned for any kind (or at
    > least, any kind that will fit).
    >
    > I can't guess what type it is on the 64-bit machine that requires
    > 16-byte alignment.


    long double could have such a requirement.
    long long could be 128 bits on a 64 bit machine, and have the same
    requirement.
    almost anything at all can have such a requirement on a DS9K

    --
    Chqrlie.
     
    Charlie Gordon, Sep 12, 2007
    #7
  8. shaanxxx

    Richard Bos Guest

    shaanxxx <> wrote:

    > On Sep 12, 4:03 pm, Ian Collins <> wrote:
    > > shaanxxx wrote:
    > > > why malloc (allocator) guarantees that address return by them will be
    > > > aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?

    > >
    > > It doesn't. It guarantees the address is suitably aligned for any type.
    > > This has to be the case because malloc returns a void* which can be
    > > assigned to any pointer type.

    >
    > http://g.oswego.edu/dl/html/malloc.html
    >
    > if you read this document, you will find that author is little keen
    > about keeping alignment at eight byte.


    Perhaps, but he's writing one for Unix. It may be that on his variant of
    Unix, 8 bytes are a reasonable granularity for memory. On some systems
    it may be larger, on some smaller. On some, it may be 1 byte. On some, a
    whole sector of 256 bytes. It all depends on the system; ISO C says
    nothing about this, except that the memory returned by malloc() must be
    aligned suitably for any object type - but again, how strict object must
    be aligned depends on the system.
    As for why these different systems require their respective alignments
    to be as strict as they are - that, too, varies with the system. On some
    it's just faster because of how their microprocessors work. On some
    others it might only be more convenient because of the OS's memory
    handler. If you want to know, read your implementation's, your OS's, and
    your hardware's manuals. ISO C, and therefore comp.lang.c, cannot tell.

    Richard
     
    Richard Bos, Sep 12, 2007
    #8
  9. shaanxxx

    pete Guest

    Richard Bos wrote:
    >
    > shaanxxx <> wrote:
    >
    > > On Sep 12, 4:03 pm, Ian Collins <> wrote:
    > > > shaanxxx wrote:
    > > > > why malloc (allocator) guarantees that address return by them will be
    > > > > aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?
    > > >
    > > > It doesn't. It guarantees the address is suitably aligned for any type.
    > > > This has to be the case because malloc returns a void* which can be
    > > > assigned to any pointer type.

    > >
    > > http://g.oswego.edu/dl/html/malloc.html
    > >
    > > if you read this document, you will find that author is little keen
    > > about keeping alignment at eight byte.

    >
    > Perhaps, but he's writing one for Unix.


    And also,
    "This article is now out of date,
    and doesn't reflect details of current version of malloc."

    --
    pete
     
    pete, Sep 13, 2007
    #9
  10. shaanxxx

    shaanxxx Guest

    On Sep 13, 5:31 am, pete <> wrote:
    > Richard Bos wrote:
    >
    > > shaanxxx <> wrote:

    >
    > > > On Sep 12, 4:03 pm, Ian Collins <> wrote:
    > > > > shaanxxx wrote:
    > > > > > why malloc (allocator) guarantees that address return by them will be
    > > > > > aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?

    >
    > > > > It doesn't. It guarantees the address is suitably aligned for any type.
    > > > > This has to be the case because malloc returns a void* which can be
    > > > > assigned to any pointer type.

    >
    > > >http://g.oswego.edu/dl/html/malloc.html

    >
    > > > if you read this document, you will find that author is little keen
    > > > about keeping alignment at eight byte.

    >
    > > Perhaps, but he's writing one for Unix.

    >
    > And also,
    > "This article is now out of date,
    > and doesn't reflect details of current version of malloc."
    >
    > --
    > pete- Hide quoted text -
    >
    > - Show quoted text -


    where i can find the current version of malloc ?
     
    shaanxxx, Sep 13, 2007
    #10
  11. shaanxxx

    Richard Bos Guest

    shaanxxx <> wrote:

    > where i can find the current version of malloc ?


    If you think that there is a real answer to that question, you are not
    yet competent enough to understand the details of any implementation of
    such a function.

    Richard
     
    Richard Bos, Sep 13, 2007
    #11
  12. shaanxxx

    Flash Gordon Guest

    shaanxxx wrote, On 13/09/07 07:55:

    <snip>

    > where i can find the current version of malloc ?


    There is NO one "current version of malloc." Each imlpementation has its
    own implementation of malloc, the source of some versions are available,
    others are not. Where to get it, if it is available, depends on your
    implementation, so ask somewhere that talks about your implementation.
    --
    Flash Gordon
     
    Flash Gordon, Sep 13, 2007
    #12
  13. shaanxxx <> writes:
    [...]
    > where i can find the current version of malloc ?


    There is no such thing as "the current version of malloc".

    The malloc function is specified by the C standard, as is its required
    behavior. Every conforming C implementation must provide an
    implementation of the malloc function; as long as it meets the
    requirements, no implementation's malloc is more or less correct than
    any other.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Sep 13, 2007
    #13
  14. (Richard Tobin) writes:
    > In article <>,
    > shaanxxx <> wrote:
    >>why malloc (allocator) guarantees that address return by them will be
    >>aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?

    >
    > Presumably on those systems there are objects that have to be aligned
    > on 8- or 16- byte boundaries. For example, it's quite likely that a
    > double is 8 bytes long and has to be 8-byte aligned. Even if it
    > doesn't *have* to be aligned, it may be more efficient if it is.
    > This varies from system to system - you can't rely on it.
    >
    > Since malloc() doesn't know what kind of object you're going to store
    > in the memory, it has to make sure it's aligned for any kind (or at
    > least, any kind that will fit).


    Actually the standard requires the memory to be aligned for any type
    whether it's big enough or not (though if an implementation violated
    this rule, it's not clear that a program could detect it).

    > I can't guess what type it is on the 64-bit machine that requires
    > 16-byte alignment.


    Possibly none. malloc is free to use stricter alignment than it has
    to (and there might be good reasons to do so).

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Sep 13, 2007
    #14
  15. In article <>,
    Keith Thompson <> wrote:

    >> Since malloc() doesn't know what kind of object you're going to store
    >> in the memory, it has to make sure it's aligned for any kind (or at
    >> least, any kind that will fit).


    >Actually the standard requires the memory to be aligned for any type
    >whether it's big enough or not (though if an implementation violated
    >this rule, it's not clear that a program could detect it).


    And if you can't detect it, the standard doesn't require it.

    You could probably (in practice) detect it by casting the pointer to
    some integer type, examining the low order bits, and trying to store
    an object at an address you determine to be misaligned within a large
    enough block. But since the standard doesn't require that the
    conversion of pointers to integers work in any particular way, you can
    only do it in practice, not theory.

    -- Richard

    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, Sep 13, 2007
    #15
  16. Keith Thompson said:

    <snip>

    > The malloc function is specified by the C standard, as is its required
    > behavior. Every conforming


    hosted

    > C implementation must provide an implementation of the malloc
    > function;


    <snip>


    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Sep 13, 2007
    #16
  17. shaanxxx

    shaanxxx Guest

    On Sep 12, 6:27 pm, (Richard Bos) wrote:
    > shaanxxx <> wrote:
    > > On Sep 12, 4:03 pm, Ian Collins <> wrote:
    > > > shaanxxx wrote:
    > > > > why malloc (allocator) guarantees that address return by them will be
    > > > > aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?

    >
    > > > It doesn't. It guarantees the address is suitably aligned for any type.
    > > > This has to be the case because malloc returns a void* which can be
    > > > assigned to any pointer type.

    >
    > >http://g.oswego.edu/dl/html/malloc.html

    >
    > > if you read this document, you will find that author is little keen
    > > about keeping alignment at eight byte.

    >
    > Perhaps, but he's writing one for Unix. It may be that on his variant of


    I think , malloc is just wrapper on some os call (brk (unix) and
    VirtualAlloc (Windows)). So chunk or memory management done by malloc
    will be same for all the kind of OS.

    please educate me how malloc algorithm will be different on different
    on OS ?
     
    shaanxxx, Sep 13, 2007
    #17
  18. shaanxxx

    Chris Dollin Guest

    shaanxxx wrote:

    > I think , malloc is just wrapper on some os call (brk (unix) and
    > VirtualAlloc (Windows)).


    Could be. (Needn't be.) It can /use/ those features without being
    a wrapper round them. It doesn't /need/ to use them, either.

    > So chunk or memory management done by malloc
    > will be same for all the kind of OS.


    No.

    Each implementation can have /it's own/ `malloc`. There's no need
    for different implementations to use the same code. There's not
    even any need for the /same/ implementation to use the same code:
    it could provide multiple different implementations, selected at
    link-time.

    > please educate me how malloc algorithm will be different on different
    > on OS ?


    /Typically/, I have read, mallocs will ask the OS [if there is one] for
    /large/ chunks of memory at a time, and sub-divide those chunks as they
    need for the client code [1]. How they do that sub-division is their
    business. They might use a buddy system, or a Big Bag Of Pages, or a
    freelist, or several freelists arranged by size. Or something.

    [1] Partly because system calls can be significantly more expensive
    than function calls, and because the system memory management
    might not be able to do the same things as malloc/free/realloc
    need to do -- like free memory between two pieces of still-
    mallocated memory.

    --
    Chris "shh! stop barking, Malloc!" Dollin

    Hewlett-Packard Limited registered no:
    registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
     
    Chris Dollin, Sep 13, 2007
    #18
  19. (Richard Tobin) writes:
    > In article <>,
    > Keith Thompson <> wrote:
    >>> Since malloc() doesn't know what kind of object you're going to store
    >>> in the memory, it has to make sure it's aligned for any kind (or at
    >>> least, any kind that will fit).

    >
    >>Actually the standard requires the memory to be aligned for any type
    >>whether it's big enough or not (though if an implementation violated
    >>this rule, it's not clear that a program could detect it).

    >
    > And if you can't detect it, the standard doesn't require it.


    There is at least one real consequence of the requirement. Converting
    from one pointer type to another invokes UB if the resulting pointer
    is not correctly aligned. So this:

    long double *ptr = malloc(1);

    does *not* invoke UB even if you can't store a long double in the
    allocated memory.

    But if the implementation doesn't impose alignment requirements on
    converted pointers, but does impose alignment requirements on objects,
    then an implementation can get away with having malloc(1) return a
    misaligned pointer without any portable program being able to detect
    it.

    What I mean by the above is, for example, if a long double object must
    always be aligned on an 8-byte boundary (attempting to read or write a
    misaligned long double invokes UB), but all pointers are just byte
    pointers, and constructing a 'long double*' that points to an odd
    address doesn't do anything nasty.

    [...]

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Sep 13, 2007
    #19
  20. shaanxxx

    Flash Gordon Guest

    Chris Dollin wrote, On 13/09/07 13:57:
    > shaanxxx wrote:
    >
    >> I think , malloc is just wrapper on some os call (brk (unix) and
    >> VirtualAlloc (Windows)).

    >
    > Could be. (Needn't be.) It can /use/ those features without being
    > a wrapper round them. It doesn't /need/ to use them, either.
    >
    >> So chunk or memory management done by malloc
    >> will be same for all the kind of OS.

    >
    > No.
    >
    > Each implementation can have /it's own/ `malloc`. There's no need
    > for different implementations to use the same code. There's not
    > even any need for the /same/ implementation to use the same code:
    > it could provide multiple different implementations, selected at
    > link-time.


    <snip>

    It could even allow you to select the implementation at run time of the
    application. One *very* big and well known company has even done this
    with the C library for its high end OS.
    --
    Flash Gordon
     
    Flash Gordon, Sep 13, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Eric
    Replies:
    10
    Views:
    571
  2. John
    Replies:
    13
    Views:
    734
  3. ravi
    Replies:
    0
    Views:
    481
  4. Peter
    Replies:
    34
    Views:
    2,058
    Richard Tobin
    Oct 22, 2004
  5. john

    Which allocator used by malloc

    john, Dec 9, 2009, in forum: C Programming
    Replies:
    11
    Views:
    843
    Phil Carmody
    Dec 11, 2009
Loading...

Share This Page