lkml.org 
[lkml]   [2006]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 0/2] KABI example conversion and cleanup
    Arjan van de Ven wrote:
    >> struct _LA(whatever) {
    >> int foo;
    >> int bar;
    >> };
    >>
    >> struct _LA(another) {
    >> ...
    >> };
    >>
    >
    > this is a good sign that this is all very over designed :)
    >
    >
    It's an eyesore, isn't it? :)
    > namespace pollution is perhaps evil, but we also should not overreact.
    > Especially for struct names. *IF* they are in a "narrow enough" header,
    > the user of the header knows what he is doing, and accepts these to be
    > in his namespace.
    >
    This is true for a small enough application. But things grow, libraries
    are added, and includes keep pulling other includes in. Sooner or later
    you'll have a collision.
    > The problem is things like u64 etc that is VERY common in all headers,
    > but then again __u64 etc are just fine, history has proven that already.
    >
    Agree. But to be on the safe side one can use uint64_t and friends
    (which the kernel can typedef to u64 and first degree relatives)

    --
    error compiling committee.c: too many arguments to function

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-03-26 20:00    [W:4.171 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site