Re: GCC 3.4 Heads-up

linux_at_horizon.com
Date: 12/26/03

  • Next message: William Lee Irwin III: "Re: 2.6.0 Huge pages not working as expected"
    Date:	26 Dec 2003 11:02:06 -0000
    To: linux-kernel@vger.kernel.org, torvalds@osdl.org
    
    

    > Similarly, what the _hell_ does the gcc extension
    >
    > int a;
    >
    > (char)a += b;
    >
    > really mean? The whole extension is just braindamaged,

    It means a = (int)((char)a + b).
    (Modulo the fact that the value of the expression is the sum of type
    char and not the final value of type int.)

    Applied to integer types, it *is* pretty brain damaged. But applied to
    pointer types, it makes a lot more sense.

    This is because "a += b" in C is actually "a += b * sizeof(*a)", and
    sometimes you want a different *a.

    In particular, 1 is a popular value.

    Consider the common case of a structure which has a bunch of variable-sized
    blocks with a standard header:

    struct foo {
            unsigned type, size;
            ...
    } a;

    Then you *do* have to write
            a = (struct foo *)((char *)a + a->size);

    and I might argue that

            (char *)a += a->size;

    is definitely cleaner.

    Or consider the case when the structure doesn't have an explicit size
    and you have a big case statement for parsing it:

    switch (a->type) {
            case BAR:
                    process_bar_chunk(((struct bar *)a)++);
                    break;
            case BAZ:
                    process_baz_chunk(((struct baz *)a)++);
                    break;
            ...
    };

    Isn't that code a bit nicer looking? I put the redundant parens
    in to remind people that I didn't mean to write "(struct bar *)(a++)"
    (which also has its legitimate uses).

    Necessary, no. But not "brain damaged", either.
    It's well-defined and has legitimate uses.
    -
    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/


  • Next message: William Lee Irwin III: "Re: 2.6.0 Huge pages not working as expected"

    Relevant Pages

    • Re: [PATCH] (18/22) task_thread_info - part 2/4
      ... That in the sum it's still the same work. ... ti6 is the sum of ti6_?, to make it easier to verify. ... There has been a bit on IRC, but I can't really discuss such things on IRC ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: A Bug in gcc or asm/string.h ?
      ... My apologies to the GCC team, in case anyone has read it. ... Indeed the compiler has to assume that any memory location has changed. ... static inline int strcmp(const char * cs,const char * ct) ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [OT] Re: 0xdeadbeef vs 0xdeadbeefL
      ... > Argh, I've mentioned BK. ... _Especially_ when it comes to signedness ... than char can represent. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] embarassing typo
      ... I was gonna ask what language is so complex as to need an 8 ... Would an 8 byte char be enough ... Copyright 2005 by Maurice Eugene Heskett, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.0-test6 scheduling(?) oddness
      ... |> some unintended behaviour before I just pass on the program. ... | it isn't doing something legitimate since as he said, ... not the reason performance is so grim, and a solution can be found. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)