macro with variable length of argument

Discussion in 'C Programming' started by ethan, Sep 25, 2005.

  1. ethan

    ethan Guest

    Hi All,

    How to write a macro with variable length of argument?
    For example, if i need a macro to check return value of printf.

    #define PRINTF_ESC(x, ...) if(printf(x, ...) == 10) goto end;

    However, it doesn't work. >_<

    Thank you very much.

    Ethan
     
    ethan, Sep 25, 2005
    #1
    1. Advertising

  2. ethan wrote on 25/09/05 :
    > How to write a macro with variable length of argument?


    C90 :

    #define PRINTF(a) print a

    usage :

    PRINTF (("Hi, I'm %d\n", 49));

    > For example, if i need a macro to check return value of printf.
    >
    > #define PRINTF_ESC(x, ...) if(printf(x, ...) == 10) goto end;
    >
    > However, it doesn't work. >_<


    It may works with C99. I'm not sure of the syntax...

    --
    Emmanuel
    The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
    The C-library: http://www.dinkumware.com/refxc.html

    ..sig under repair
     
    Emmanuel Delahaye, Sep 25, 2005
    #2
    1. Advertising

  3. (supersedes <>)

    ethan wrote on 25/09/05 :
    > How to write a macro with variable length of argument?


    C90 :

    #define PRINTF(a) printf a

    usage :

    PRINTF (("Hi, I'm %d\n", 49));

    > For example, if i need a macro to check return value of printf.
    >
    > #define PRINTF_ESC(x, ...) if(printf(x, ...) == 10) goto end;
    >
    > However, it doesn't work. >_<


    It may works with C99. I'm not sure of the syntax...


    --
    Emmanuel
    The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
    The C-library: http://www.dinkumware.com/refxc.html

    "There are 10 types of people in the world today;
    those that understand binary, and those that dont."
     
    Emmanuel Delahaye, Sep 25, 2005
    #3
  4. ethan

    SM Ryan Guest

    "ethan" <> wrote:
    # Hi All,
    #
    # How to write a macro with variable length of argument?
    # For example, if i need a macro to check return value of printf.
    #
    # #define PRINTF_ESC(x, ...) if(printf(x, ...) == 10) goto end;

    You can do it with double parentheses. (Note no parentheses
    after printf.)

    @ more t.c
    #define PRINTF_ESC(x) if(printf x == 10) goto end;
    PRINTF_ESC((a))
    PRINTF_ESC((a,b,c,d))

    @ cc -E t.c
    # 1 "t.c"
    # 1 "<built-in>"
    # 1 "<command line>"
    # 1 "t.c"

    if(printf (a) == 10) goto end;
    if(printf (a,b,c,d) == 10) goto end;


    I think gcc has an extension for this, but it might not
    be available elsewhere.

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    OOOOOOOOOO! NAVY SEALS!
     
    SM Ryan, Sep 25, 2005
    #4
  5. ethan wrote:
    > How to write a macro with variable length of argument?


    Don't.

    > For example, if i need a macro to check return value of printf.


    Then you write a function doing that, somewhere along these lines:

    void foo( char const* fmt, ...)
    {
    va_list args;
    va_start( args, fmt);
    if(42 != vprintf( fmt, args))
    exit(667);
    }

    Macros are evil.

    Uli
     
    Ulrich Eckhardt, Sep 25, 2005
    #5
  6. ethan wrote:
    > Hi All,
    >
    > How to write a macro with variable length of argument?
    > For example, if i need a macro to check return value of printf.
    >
    > #define PRINTF_ESC(x, ...) if(printf(x, ...) == 10) goto end;
    >
    > However, it doesn't work. >_<
    >
    > Thank you very much.
    >
    > Ethan


    In C99 you can do the following:

    #define PRINTF_ESC(x, ...) if(printf(x, __VA_ARGS__) == 10) goto end;

    The only problem with this is that PRINTF_ESC will require two or more
    parameters, since the elispses must hold one or more parameters. A
    better way to do this would be:

    #define PRINTF_ESC(...) if(printf(__VA_ARGS__) == 10) goto end;

    FYI: it is bad to use goto's (especially in a macro definition!) and
    customary to leave the semicolon off the end of you macro definition or
    to do the following:
    #define PRINTF_ESC(...) do { if(printf(__VA_ARGS__) == 10) goto end; }
    while (0)

    Also note that the meaning of the elipses in macro functions is much
    different than in real functions and as another poster mentions your
    better off using a real function for this (that way you can't use a
    goto ;).

    Also see http://www.delorie.com/gnu/docs/gcc/cpp_19.html

    -Charlie
     
    Charles Mills, Sep 25, 2005
    #6
  7. ethan

    Stan Milam Guest

    Ulrich Eckhardt wrote:
    > Macros are evil.
    >
    > Uli
    >


    Why?
     
    Stan Milam, Sep 25, 2005
    #7
  8. ethan

    Skarmander Guest

    Stan Milam wrote:
    > Ulrich Eckhardt wrote:
    >
    >> Macros are evil.
    >>

    >
    > Why?


    If ya hafta ask, ye'll never know!

    That said, "macros are evil" is primarily a cry from the C++ camp, see
    for example
    http://www.parashift.com/c -faq-lite/inline-functions.html#faq-9.5

    While preferring inline functions and constants to macros is good
    advice, C programmers can't and won't do it. Can't because, before C99
    (which will take another, oh, ten years or so to catch on), there was no
    standard mechanism for inlining functions, won't because it's a staple
    of C culture.

    The use of #define for symbolic constants is so ingrained that it will
    probably remain part of C until the time_t's wrap around, but luckily
    their use is disciplined enough not to cause much trouble... usually.
    Ditto on include guards: #ifndef HEADER_H #define HEADER_H... Go beyond
    that and it quickly goes downhill.

    The preprocessor unlocks power programmers are all too eager to (ab)use.
    More than a few times I've stared at a jungle of ALL-CAPS code where
    "convenient" macros effectively defined a completely new language
    because the perpetrators either loathed typing or apparently believed
    that by hiding crud behind macros, it stops being crud. When you have to
    tell your compiler to give you the preprocessor output to pore over
    because you're tired of chasing include files for the definitions, you
    know you're having a bad day.

    S.
     
    Skarmander, Sep 25, 2005
    #8
  9. Skarmander wrote:
    > That said, "macros are evil" is primarily a cry from the C++ camp, see
    > for example
    > http://www.parashift.com/c -faq-lite/inline-functions.html#faq-9.5


    Hmmm, I don't think there is anything that only applies to C++ but several
    reasons are given in that FAQ so it could be interesting reading even for
    a C programmer. Multiple evaluation of side-effects, the absolute
    disrespect for scoping rules, the fact that they can be replaced with
    inline functions (in many cases) are those that immediately jump to my
    mind.

    > While preferring inline functions and constants to macros is good
    > advice, C programmers can't and won't do it. Can't because, before C99
    > (which will take another, oh, ten years or so to catch on), there was no
    > standard mechanism for inlining functions, won't because it's a staple
    > of C culture.


    I hope I misunderstand you here, or are you really saying that macro
    functions are part of C culture and therefore you are using them even if
    there are better alternatives?

    Anyhow, I never found a compiler that did not understand inline (yes, a few
    of them needed __inline or __inline__, a case where the preprocessor can
    be made good use of). I admit I don't do much programming on legacy
    systems though, so it might be possible that such compilers still exist.
    None of the compilers I did and do C with claimed C99 conformance btw,
    except for newer gccs perhaps.

    > The use of #define for symbolic constants is so ingrained that it will
    > probably remain part of C until the time_t's wrap around, but luckily
    > their use is disciplined enough not to cause much trouble... usually.


    AFAIK, C has another big problem in that aspect, a constant does not
    constitute an 'integral constant expression', i.e. it can't be used
    specify the size of an array. I'm rather sure of this for C89, not so sure
    about C99.

    Hmm, maybe this is the reason you attribute 'macros are evil' to C++ since
    in C++ 'inline' is part of the language and constants can be used to
    declare arrays, so two possible reasons that you need them are gone.


    > Ditto on include guards: #ifndef HEADER_H #define HEADER_H... Go beyond
    > that and it quickly goes downhill.


    Those are the best present solution for something that should be a proper
    part of the language. It doesn't justify using macros in places where a
    better alternative exists.

    > The preprocessor unlocks power programmers are all too eager to (ab)use.
    > More than a few times I've stared at a jungle of ALL-CAPS code where
    > "convenient" macros effectively defined a completely new language
    > because the perpetrators either loathed typing or apparently believed
    > that by hiding crud behind macros, it stops being crud. When you have to
    > tell your compiler to give you the preprocessor output to pore over
    > because you're tired of chasing include files for the definitions, you
    > know you're having a bad day.


    My heart feels with you. I've been refactoring someone else's code for the
    last three weeks and will probably go on with it this week. This code
    didn't contain an overabundance of macros but showed a serious
    misunderstanding of how to use a typed language and OO design. It's not
    even C FWIW.

    Uli
     
    Ulrich Eckhardt, Sep 25, 2005
    #9
  10. ethan

    SM Ryan Guest

    Ulrich Eckhardt <> wrote:
    # ethan wrote:
    # > How to write a macro with variable length of argument?
    #
    # Don't.

    You can't use goto from one function to another.
    You would have to set up a longjmp.

    # Then you write a function doing that, somewhere along these lines:
    #
    # void foo( char const* fmt, ...)
    # {
    # va_list args;
    # va_start( args, fmt);
    # if(42 != vprintf( fmt, args))
    # exit(667);

    It used a goto, not an exit.


    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    What kind of convenience store do you run here?
     
    SM Ryan, Sep 25, 2005
    #10
  11. ethan

    SM Ryan Guest

    Skarmander <> wrote:
    # Stan Milam wrote:
    # > Ulrich Eckhardt wrote:
    # >
    # >> Macros are evil.
    # >>
    # >
    # > Why?
    #
    # If ya hafta ask, ye'll never know!

    You know, one of the first things people do with an
    assembler is to write an evil macro processor.

    They do the same evil with shell aliasses.

    I wonder why people do these evil things so often?
    Naturally evil?

    # The use of #define for symbolic constants is so ingrained that it will

    I wonder how you would do something like this without #defines
    #ifdef __MACHINE1__
    #define Sformat "%lld"
    #define Tformat "%ld"
    #endif
    #ifdef __MACHINE2__
    #define Sformat "%f"
    #define Tformat "%d"
    #endif
    S x; T y;
    priintf("aleph " Sformat " beth " Tformat " gimel\n",S,T);
    without having to do a malloc and strcpys.

    # that by hiding crud behind macros, it stops being crud. When you have to
    # tell your compiler to give you the preprocessor output to pore over
    # because you're tired of chasing include files for the definitions, you
    # know you're having a bad day.

    Testify, brother! I mean I see people using these 'functions'
    and the code is off in some other file. And you're constantly
    flipping back and forth because the original coder expected me
    to understand how to use 'abstractions'.

    Can you imagine the nerve of some people?

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    Why are we here?
    whrp
     
    SM Ryan, Sep 25, 2005
    #11
  12. ethan

    Skarmander Guest

    SM Ryan wrote:
    > Skarmander <> wrote:
    > # Stan Milam wrote:
    > # > Ulrich Eckhardt wrote:
    > # >
    > # >> Macros are evil.
    > # >>
    > # >
    > # > Why?
    > #
    > # If ya hafta ask, ye'll never know!
    >
    > You know, one of the first things people do with an
    > assembler is to write an evil macro processor.
    >
    > They do the same evil with shell aliasses.
    >
    > I wonder why people do these evil things so often?
    > Naturally evil?
    >

    No, it's because textual replacement is one of the most obvious things a
    computer can do. By layering it over a language not based on text
    replacement, you get a more powerful language. In fact, you get a *much*
    more powerful language. One that is able to transcend the more mundane
    considerations of syntax and structure on its lower level.

    Assembler and shell constructs are in dire need of this power boost. A
    high-level language (even a "high-level assembler" like C) shouldn't be,
    it has ways of implementing abstraction itself. At best text replacement
    should be used conservatively, where in-language constructs just won't do.

    > # The use of #define for symbolic constants is so ingrained that it will
    >
    > I wonder how you would do something like this without #defines
    > #ifdef __MACHINE1__
    > #define Sformat "%lld"
    > #define Tformat "%ld"
    > #endif
    > #ifdef __MACHINE2__
    > #define Sformat "%f"
    > #define Tformat "%d"
    > #endif
    > S x; T y;
    > priintf("aleph " Sformat " beth " Tformat " gimel\n",S,T);
    > without having to do a malloc and strcpys.
    >

    That's easy, use C++ and overload operator<<.

    But less jocularly, yeah, I can't have my cake and eat it too. If you
    don't use the preprocessor for conditional compilation in this case, you
    can't construct the printf() format string at compile time. You'll
    either need to construct the string dynamically or use more printf()
    statements (I'd go for the latter, by the way). There goes my whole
    argument right there.

    Or not. I never said macros are simply not to be used, after all.

    > # that by hiding crud behind macros, it stops being crud. When you have to
    > # tell your compiler to give you the preprocessor output to pore over
    > # because you're tired of chasing include files for the definitions, you
    > # know you're having a bad day.
    >
    > Testify, brother! I mean I see people using these 'functions'
    > and the code is off in some other file. And you're constantly
    > flipping back and forth because the original coder expected me
    > to understand how to use 'abstractions'.
    >
    > Can you imagine the nerve of some people?
    >

    Hmm, do I taste the sharp barbs of sarcasm raking over my back there?

    There are, of course, a few subtle differences between macros and
    functions in the abstraction department, and especially in how clear the
    abstraction is, and over how many include files said abstractions have
    been scattered, and how much help the compiler offers you in detecting
    incorrect use, and the difference between doing something *in* a
    language and doing something *with* a language (or dare I say *to* a
    language).

    But if you think it's more constructive to pretend I'm just not suave
    enough to match the amazing powers of abstraction people use when they
    give me a list of struct declarations composed entirely of macros, go ahead.

    Yes, I *am* making an argument of degree here.

    S.
     
    Skarmander, Sep 25, 2005
    #12
  13. ethan

    Skarmander Guest

    Ulrich Eckhardt wrote:
    > Skarmander wrote:

    <snip>
    >>While preferring inline functions and constants to macros is good
    >>advice, C programmers can't and won't do it. Can't because, before C99
    >>(which will take another, oh, ten years or so to catch on), there was no
    >>standard mechanism for inlining functions, won't because it's a staple
    >>of C culture.

    >
    >
    > I hope I misunderstand you here, or are you really saying that macro
    > functions are part of C culture and therefore you are using them even if
    > there are better alternatives?
    >

    No. I'm saying people in general do this, and that they will also
    dispute what's "better".

    > Anyhow, I never found a compiler that did not understand inline (yes, a few
    > of them needed __inline or __inline__, a case where the preprocessor can
    > be made good use of). I admit I don't do much programming on legacy
    > systems though, so it might be possible that such compilers still exist.
    > None of the compilers I did and do C with claimed C99 conformance btw,
    > except for newer gccs perhaps.
    >

    The problem I see is that people will reach for the preprocessor first,
    and inline (or __inline or __inline__) second, precisely because
    everyone knows and loves the preprocessor. This is especially tempting
    for those oneliners you *could* turn into a proper function, but don't.

    Projects that make heavy use of inlined functions typically do approach
    the problem systematically and use a #define (yes!) with INLINE
    expanding to whatever keyword is appropriate. (See? Another valid use of
    the preprocessor. :) But most people won't bother with the set-up.

    Another common use of the preprocessor is for "generic" functions. You know:

    #define max(x, y) ((x) > (y) ? (x) : (y))

    Much clearer than writing that silly ternary operator all the time, and
    see how it works regardless of type?

    Incidentally, this particular macro cost me quite a bit of time to track
    down in the header files supplied with Visual Studio, as it caused
    compilation of a C++ program that used the max function in the standard
    library to fail. I finally found the #define, and the NOMINMAX define
    that would turn it off. Joy. (I'm sure they've fixed this problem by
    now, but I haven't checked.)

    >>The use of #define for symbolic constants is so ingrained that it will
    >>probably remain part of C until the time_t's wrap around, but luckily
    >>their use is disciplined enough not to cause much trouble... usually.

    >
    >
    > AFAIK, C has another big problem in that aspect, a constant does not
    > constitute an 'integral constant expression', i.e. it can't be used
    > specify the size of an array. I'm rather sure of this for C89, not so sure
    > about C99.
    >

    And exactly because of this sort of confusion, people will prefer to use
    a #define where at least they know they'll get a constant number, not
    a readonly-but-not-really-a-constant variable they have to declare
    "extern" and other bothersome constructs. "const" is a bit of a misnomer.

    > Hmm, maybe this is the reason you attribute 'macros are evil' to C++ since
    > in C++ 'inline' is part of the language and constants can be used to
    > declare arrays, so two possible reasons that you need them are gone.
    >

    It did start with C++, when people observed that these constructs made
    the language capable of doing a common thing directly, rather than
    needing the preprocessor as a crutch. I'm sure quite a few people still
    don't get what the fuss is about.

    >>Ditto on include guards: #ifndef HEADER_H #define HEADER_H... Go beyond
    >>that and it quickly goes downhill.

    >
    > Those are the best present solution for something that should be a proper
    > part of the language. It doesn't justify using macros in places where a
    > better alternative exists.
    >

    <snip>
    Yes, the keyword in all of these things is "where a better alternative
    exists". Keep in mind that "better" is also subjective, as per elsewhere
    in this thread. If it's very important to you that everything happens at
    compile time, for example, you may be required to use macros for things
    that could very well be done in the language itself, but that you're
    just not willing to pay the cost for.

    The include guards problem is part of C's barebones approach to
    dependency management, in that it has none, and expects you to pick up
    the slack. I'm sure many people actually like *that*, too.

    S.
     
    Skarmander, Sep 25, 2005
    #13
  14. On Sun, 25 Sep 2005 21:06:21 +0200, in comp.lang.c , Ulrich Eckhardt
    <> wrote:

    >Skarmander wrote:
    >> That said, "macros are evil" is primarily a cry from the C++ camp, see
    >> for example
    >> http://www.parashift.com/c -faq-lite/inline-functions.html#faq-9.5

    >
    >Hmmm, I don't think there is anything that only applies to C++ but several
    >reasons are given in that FAQ so it could be interesting reading even for
    >a C programmer.


    My first comment on that site would be that it seems to be written by
    someone who dislikes macros, and so its not exactly an impartial
    reference. All of his 'evils' can be trivially avoided by the usual
    method - learning how to programme the language, instead of assuming
    its the same as another one you already know....

    More importantly C++ has other ways to do the same thing as #define
    whereas the same logic doesn't apply in C. ISTR how const works is an
    example.

    >I hope I misunderstand you here, or are you really saying that macro
    >functions are part of C culture and therefore you are using them even if
    >there are better alternatives?


    Partly.

    >Anyhow, I never found a compiler that did not understand inline


    I've come across several, but its irrelevant since the C standard
    didn't require it to be supported.

    >AFAIK, C has another big problem in that aspect, a constant does not
    >constitute an 'integral constant expression',


    A constant most certainly can. You're confusing const with constant.
    Remember that in C, a const object is not a constant.

    >Hmm, maybe this is the reason you attribute 'macros are evil' to C++ since
    >in C++ 'inline' is part of the language and constants can be used to
    >declare arrays, so two possible reasons that you need them are gone.


    Assuming by "constant" you refer to const objects, then you're quite
    right. C++, being a different language, has different ways of
    achieving the same effect.

    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

    ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
     
    Mark McIntyre, Sep 25, 2005
    #14
  15. ethan

    Imre Palik Guest

    Stan Milam <> writes:

    > Ulrich Eckhardt wrote:
    > > Macros are evil.
    > > Uli
    > >

    >
    > Why?


    It can make a perfectly good day bad, when you have to figure out why that
    damned thing don't compile, and all you did was to #include another file.

    For small projects, with a handful of developpers they ar OK, I guess, but
    they don't scale well beyond this.

    As a rule of thumb, I'd say use them only when you definitely must. I.e.,
    you are using __FILE__, __LINE__, etc.; you are using the # or ##; you want
    compile-time constants; you are fighting a performance bottleneck with C89
    and you need inlining.

    ImRe
     
    Imre Palik, Sep 26, 2005
    #15
  16. On 26 Sep 2005 08:54:01 +0200, in comp.lang.c , "Imre Palik"
    <> wrote:

    <of macros, I think>

    >For small projects, with a handful of developpers they ar OK, I guess, but
    >they don't scale well beyond this.


    I guess our 2.5 MLOC app, with around 40 developers spread through
    three global sites, counts as small then.... :)

    >you are fighting a performance bottleneck with C89
    >and you need inlining.


    Performance bottlenecks are defined by QOI not by the Standard.
    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

    ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
     
    Mark McIntyre, Sep 26, 2005
    #16
  17. ethan

    Imre Palik Guest

    Mark McIntyre <> writes:

    > On 26 Sep 2005 08:54:01 +0200, in comp.lang.c , "Imre Palik"
    > <> wrote:
    >
    > <of macros, I think>
    >
    > >For small projects, with a handful of developpers they ar OK, I guess, but
    > >they don't scale well beyond this.

    >
    > I guess our 2.5 MLOC app, with around 40 developers spread through
    > three global sites, counts as small then.... :)


    Possibly. At least I never worked on such a small project before.
    (100-500 developpers, 3-4 global sites. I never had the access rights to
    count all the LOC ...). Luckily there was almost no macros in the previous
    projects I worked on. So I only encountered with my first ever macro name
    collision error a couple of weeks before. Interestingly, it was not me,
    who wrote the macros. I only happened to include a bunch of headers in
    such an order, that the macros within are generated invalid C code.

    > >you are fighting a performance bottleneck with C89
    > >and you need inlining.

    >
    > Performance bottlenecks are defined by QOI not by the Standard.


    Yeah. But the tools one can use to solve them are defined by the
    standard. And macros provide guaranteed inlining.

    If one can prove (preferably with measurements), that this capability
    outweights the danger of using them, then their use is 100% justified.
    Otherwise it might hurt somebody somewhat later without any real gain.

    ImRe
     
    Imre Palik, Sep 27, 2005
    #17
  18. On 27 Sep 2005 12:51:38 +0200, in comp.lang.c , "Imre Palik"
    <> wrote:

    (of a mere 2.5 MLOC and 30-40 developer project)

    >I never worked on such a small project before.
    >(100-500 developpers, 3-4 global sites.


    I suspect its impossible for 100-500 developers to work on a single
    project at once. My guess is this is a "project" like MS Office is a
    project, or Linux is a project - ie its actually several dozen smaller
    but linked projects with shared modules. YMMV of course.

    >So I only encountered with my first ever macro name
    >collision error a couple of weeks before.


    IME macro name collisions occur because there are no company
    standards. If you name macros using some conventions, clashes are
    ironed out during code review.

    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

    ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
     
    Mark McIntyre, Sep 27, 2005
    #18
    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. ANDERS FLODERUS
    Replies:
    1
    Views:
    381
    Rob Williscroft
    Dec 20, 2003
  2. Ben Kial
    Replies:
    1
    Views:
    705
    Eric Enright
    Nov 15, 2004
  3. S?ren Gammelmark
    Replies:
    1
    Views:
    1,971
    Eric Sosman
    Jan 7, 2005
  4. jake1138
    Replies:
    5
    Views:
    1,087
    Dave Thompson
    Feb 14, 2005
  5. AikidoGuy
    Replies:
    11
    Views:
    586
    Seebs
    Nov 21, 2011
Loading...

Share This Page