[lkml]   [2005]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: p = kmalloc(sizeof(*p), )
    On Sun, Sep 18, 2005 at 10:34:16PM +0200, Roman Zippel wrote:
    > > Ewwwww... I'd say that it qualifies as one hell of a bug (and yes, at least
    > > 3.3 and 4.0.1 are still doing that). What a mess...
    > It's not a bug, it's exactly what you're asking for, e.g. "*p1 = *p2"
    > translates to memcpy. gcc also can't simply initialize that structure in
    > place, e.g. you could do something like this (not necessarily useful but
    > still valid): "*p = (struct foo){..., bar(p),...};".
    > In the end it all depends on how good gcc can optimize away the memcpy,
    > but initially there is always a memcpy.

    No. Assignment is _not_ defined via memcpy(); it's a primitive that could
    be implemented that way. Choosing such (pretty much worst-case) implementation
    in every case is a major bug in code generator.

    You _can_ introduce a new local variable for each arithmetic operation in
    your function and store result of operation in the corresponding variable.
    As the matter of fact, this is a fairly common intermediate form. However,
    if compiler ends up leaving all these suckers intact in the final code,
    it has a serious problem.

    Compound literal _is_ an object, all right. However, decision to allocate
    storage for given object is up to compiler and it's hardly something unusual.
    "Value of right-hand side is not needed to finish calculating left-hand side,
    so its storage is fair game from that point on" is absolutely normal.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-09-18 23:14    [W:0.027 / U:10.096 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site