compiler switch to indicate "end of function"?

Discussion in 'C Programming' started by David Mathog, May 10, 2011.

  1. David Mathog

    David Mathog Guest

    Sometimes when editing a source file a close brace is accidentally
    deleted, and when that happens, at least with gcc, the error messages
    are not very helpful in locating the error. Error messages are
    generated from code below it, although not necessarily very near to
    it, going on sometimes to the end of the file, thousands of lines
    later. These errors can propagate through dozens of functions. Which
    makes me wonder if there is something in the standard like:

    #endfunction

    to tell the compiler that if there is anything dangling in a function
    at that point to throw an error there, and to start over cleanly below
    the compiler directive. So that when

    void somefunc(void){
    /* bunch of stuff, including one too few "}" */
    }
    #endfunction

    it will be clear from the messages that the problem is in somefunc().
    In some instances I have had to emulate this by cutting off large
    chunks of a file with

    #ifdef NOTDEFINED

    until the code is small enough to find the error.

    Thanks,

    David Mathog
    David Mathog, May 10, 2011
    #1
    1. Advertising

  2. David Mathog

    Tom St Denis Guest

    On May 10, 12:00 pm, David Mathog <> wrote:
    > Sometimes when editing a source file a close brace is accidentally
    > deleted, and when that happens, at least with gcc, the error messages
    > are not very helpful in locating the error.  Error messages are
    > generated from code below it, although not necessarily very near to
    > it, going on sometimes to the end of the file, thousands of lines
    > later.  These errors can propagate through dozens of functions.  Which
    > makes me wonder if there is something in the standard like:
    >
    > #endfunction
    >
    > to tell the compiler that if there is anything dangling in a function
    > at that point to throw an error there, and to start over cleanly below
    > the compiler directive.  So that when
    >
    > void somefunc(void){
    > /* bunch of stuff, including one too few "}" */}
    >
    > #endfunction


    This problem can be mitigated a bit by factoring your code so you
    don't put many functions in a single file [or compilation unit]. I
    usually hit the analogue of this problem when missing a ';' from a
    header file, the compiler [gcc] goes off on a rant about invalid asm
    declarations or whatever. Though with experience I know exactly what
    went wrong.

    Also, compile early and often. It helps weed out these annoying
    configuration/layout/etc errors.

    Tom
    Tom St Denis, May 10, 2011
    #2
    1. Advertising

  3. David Mathog

    Ben Pfaff Guest

    David Mathog <> writes:

    > Sometimes when editing a source file a close brace is accidentally
    > deleted, and when that happens, at least with gcc, the error messages
    > are not very helpful in locating the error. Error messages are
    > generated from code below it, although not necessarily very near to
    > it, going on sometimes to the end of the file, thousands of lines
    > later.


    If you have an auto-indenting editor, just tell it to re-indent
    the whole file and look for the spot where the left margin shifts
    rightward a tab stop. It's usually obvious.

    If you are using a version-control system (and if not, why not?),
    look at the diff against the last checked-in version. If it's
    indeed a file with thousands of lines, probably the actual
    changes are much smaller and you may be able to easily pick out
    where you deleted a closing brace.

    Try using another compiler or C parser. GCC is excessively
    forgiving because it allows nested function definitions; other
    compilers will give an error at the first nested function
    definition, since they don't have that extension.
    --
    Ben Pfaff
    http://benpfaff.org
    Ben Pfaff, May 10, 2011
    #3
  4. David Mathog <> writes:
    > Sometimes when editing a source file a close brace is accidentally
    > deleted, and when that happens, at least with gcc, the error messages
    > are not very helpful in locating the error. Error messages are
    > generated from code below it, although not necessarily very near to
    > it, going on sometimes to the end of the file, thousands of lines
    > later. These errors can propagate through dozens of functions. Which
    > makes me wonder if there is something in the standard like:
    >
    > #endfunction
    >
    > to tell the compiler that if there is anything dangling in a function
    > at that point to throw an error there, and to start over cleanly below
    > the compiler directive. So that when
    >
    > void somefunc(void){
    > /* bunch of stuff, including one too few "}" */
    > }
    > #endfunction
    >
    > it will be clear from the messages that the problem is in somefunc().
    > In some instances I have had to emulate this by cutting off large
    > chunks of a file with
    >
    > #ifdef NOTDEFINED
    >
    > until the code is small enough to find the error.


    There's nothing like that in the standard, and I've never heard of
    any compiler providing it as an extension.

    When you get a syntax error, it's often best to ignore everything
    but the first error message. Anything after that tends to be the
    result of the compiler's attempt to recover and continue parsing,
    and C's grammar is such that the attempt often fails.

    If I suspect I've left out a closing brace, I'll go to the line in
    the source file corresponding to the first error message, then go
    from there to the opening '{' of the enclosing function and try
    to find the matching '}'. (In vi/vim, '%' jumps to the matching
    brace; other editors should have something similar). If there is no
    matching '}', or if there is but it's not at the right indentation,
    I start looking at enclosed brace pairs.

    Running the source file through a formatter ("indent -kr", for
    example, or a "reformat source" command if you use a GUI IDE)
    might also be helpful in narrowing down the problem.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, May 10, 2011
    #4
  5. On May 10, 6:00 pm, David Mathog <> wrote:
    > Sometimes when editing a source file a close brace is accidentally
    > deleted, and when that happens, at least with gcc, the error messages
    > are not very helpful in locating the error.  Error messages are
    > generated from code below it, although not necessarily very near to
    > it, going on sometimes to the end of the file, thousands of lines
    > later.  These errors can propagate through dozens of functions.  Which
    > makes me wonder if there is something in the standard like:
    >
    > #endfunction
    >
    > to tell the compiler that if there is anything dangling in a function
    > at that point to throw an error there, and to start over cleanly below
    > the compiler directive.  So that when
    >
    > void somefunc(void){
    > /* bunch of stuff, including one too few "}" */}
    >
    > #endfunction
    >
    > it will be clear from the messages that the problem is in somefunc().
    > In some instances I have had to emulate this by cutting off large
    > chunks of a file with
    >
    > #ifdef NOTDEFINED
    >
    > until the code is small enough to find the error.
    >
    > Thanks,
    >
    > David Mathog


    Ok. I;m sure i'll get the same flak as last time for supplying some
    good advice, but your coding style is the main culprit, i think.
    Instead of acknowledging the braces as the important structural
    elements they are, your treat them like bums and try to hide them, as
    if hey don't really matter.

    if instead of


    void somefunc(void){
    /* bunch of stuff, including one too few "}" */}

    you write

    void somefunc(void)
    {
    #if 0
    {
    bunch of stuff,
    {
    /* Some comment */
    including one too few "{" and "}"
    }
    /* some more comment */
    }
    #endif
    }

    I'm sure you'll make a lot less errors. Braces are so important in
    determining the structure of a C program, they deserve their own line.
    And don't try to tell me that whitespace costs money, since that's
    only valid on paper.
    Kleuskes & Moos, May 10, 2011
    #5
  6. David Mathog

    Seebs Guest

    On 2011-05-10, Kleuskes & Moos <> wrote:
    > {
    > /* Some comment */
    > including one too few "{" and "}"
    > }


    > I'm sure you'll make a lot less errors. Braces are so important in
    > determining the structure of a C program, they deserve their own line.


    This is not 1TBS. Therefore it's wrong.

    Here's the thing: Brace styles are all viable. Any of them will work.
    But it's VERY useful to have everyone use the same style.

    There is no way to pick a standard except by appeal to authority. Therefore,
    use the brace style from K&R. That's the closest we'll ever have to a
    proper authority.

    > And don't try to tell me that whitespace costs money, since that's
    > only valid on paper.


    It's not money, it's visual real estate. I can only see so many lines
    at a time. Seeing a few more lines of code at a time is a pretty noticeable
    payoff.

    -s
    --
    Copyright 2011, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
    Seebs, May 10, 2011
    #6
  7. David Mathog

    David Mathog Guest

    On May 10, 10:30 am, Ben Pfaff <> wrote:
    > David Mathog <> writes:
    > > Sometimes when editing a source file a close brace is accidentally
    > > deleted, and when that happens, at least with gcc, the error messages
    > > are not very helpful in locating the error.  Error messages are
    > > generated from code below it, although not necessarily very near to
    > > it, going on sometimes to the end of the file, thousands of lines
    > > later.

    >
    > If you have an auto-indenting editor, just tell it to re-indent
    > the whole file and look for the spot where the left margin shifts
    > rightward a tab stop.  It's usually obvious.
    >
    > If you are using a version-control system (and if not, why not?),
    > look at the diff against the last checked-in version.  If it's
    > indeed a file with thousands of lines, probably the actual
    > changes are much smaller and you may be able to easily pick out
    > where you deleted a closing brace.
    >
    > Try using another compiler or C parser.  GCC is excessively
    > forgiving because it allows nested function definitions; other
    > compilers will give an error at the first nested function
    > definition, since they don't have that extension.
    > --
    > Ben Pfaffhttp://benpfaff.org
    David Mathog, May 10, 2011
    #7
  8. David Mathog

    David Mathog Guest

    On May 10, 10:30 am, Ben Pfaff <> wrote:

    > Try using another compiler or C parser.  GCC is excessively
    > forgiving because it allows nested function definitions;


    Ah, so that's why it goes on so long. So I can get a similar result
    with:

    -fno-nested-functions

    Might as well add that, as I don't think I have ever intentionally
    used a nested function.

    Thanks,

    David Mathog
    David Mathog, May 10, 2011
    #8
  9. On May 10, 11:22 pm, Seebs <> wrote:
    > On 2011-05-10, Kleuskes & Moos <> wrote:
    >
    > >     {
    > >       /* Some comment */
    > >       including one too few "{" and "}"
    > >     }
    > > I'm sure you'll make a lot less errors. Braces are so important in
    > > determining the structure of a C program, they deserve their own line.

    >
    > This is not 1TBS.  Therefore it's wrong.


    :).


    > Here's the thing:  Brace styles are all viable.  Any of them will work.
    > But it's VERY useful to have everyone use the same style.


    True. It's also very handy to be able to easily spot where you went
    wrong, especially with important language elements such as braces. If
    you think otherwise, feel free to do it otherwise.

    Many program-editors offer nice colorful indicators to match '{' with
    '}' and '(' with ')'. I suggest you turn that on, too.

    > There is no way to pick a standard except by appeal to authority.


    I'm merely offering a colleage some advice that worked quite good for
    me. All the places i worked that actually HAD a formalized coding
    style (the best half of my employers, and you don't wanna know about
    the worst ones), demanded separate lines for braces. But that's just
    me and those silly employers of mine.

    > Therefore, use the brace style from K&R.  That's the closest we'll ever
    > have to a proper authority.


    Arguments from authoroty are never quite satisfying, and a debate is
    quite useless (and endless), so i'm not getting into that. In my
    current firm, where I am the sole and undisputed authority on these
    matters, K&R can go screw themselves in this respect, however much i
    admire them for their work.

    What you do in your code, is your business.

    > > And don't try to tell me that whitespace costs money, since that's
    > > only valid on paper.

    >
    > It's not money, it's visual real estate.  I can only see so many lines
    > at a time.  Seeing a few more lines of code at a time is a pretty noticeable
    > payoff.


    After years of contemplating the matter, i arrived at the conclusion
    that it is unwise to want as much information as possible on your
    screen. What you want is the _right_ information, and to be able to
    spot it quickly.
    Kleuskes & Moos, May 11, 2011
    #9
  10. David Mathog

    Ian Collins Guest

    On 05/11/11 09:22 AM, Seebs wrote:
    > On 2011-05-10, Kleuskes& Moos<> wrote:
    >
    >> And don't try to tell me that whitespace costs money, since that's
    >> only valid on paper.

    >
    > It's not money, it's visual real estate. I can only see so many lines
    > at a time. Seeing a few more lines of code at a time is a pretty noticeable
    > payoff.


    I can see 112 lines with the large font I use, but I doubt I can parse
    them all at once. I add whitespace and braces to break the code up into
    visually distinct blocks. When I could only see a fraction the number
    of lines (despite better eyesight!), I wrote denser code.

    Displays have improved beyond recognition in the last 20 years and
    coding styles should adapt to suit.

    --
    Ian Collins
    Ian Collins, May 11, 2011
    #10
  11. "Kleuskes & Moos" <> writes:
    > On May 10, 6:00 pm, David Mathog <> wrote:
    >> Sometimes when editing a source file a close brace is accidentally
    >> deleted, and when that happens, at least with gcc, the error messages
    >> are not very helpful in locating the error.  Error messages are
    >> generated from code below it, although not necessarily very near to
    >> it, going on sometimes to the end of the file, thousands of lines
    >> later.  These errors can propagate through dozens of functions.  Which
    >> makes me wonder if there is something in the standard like:
    >>
    >> #endfunction
    >>
    >> to tell the compiler that if there is anything dangling in a function
    >> at that point to throw an error there, and to start over cleanly below
    >> the compiler directive.  So that when
    >>
    >> void somefunc(void){
    >> /* bunch of stuff, including one too few "}" */}
    >>
    >> #endfunction
    >>
    >> it will be clear from the messages that the problem is in somefunc().
    >> In some instances I have had to emulate this by cutting off large
    >> chunks of a file with
    >>
    >> #ifdef NOTDEFINED
    >>
    >> until the code is small enough to find the error.
    >>
    >> Thanks,
    >>
    >> David Mathog

    >
    > Ok. I;m sure i'll get the same flak as last time for supplying some
    > good advice, but your coding style is the main culprit, i think.
    > Instead of acknowledging the braces as the important structural
    > elements they are, your treat them like bums and try to hide them, as
    > if hey don't really matter.
    >
    > if instead of
    >
    >
    > void somefunc(void){
    > /* bunch of stuff, including one too few "}" */}


    But that's not what he wrote. You put the closing brace at the end of a
    line; he didn't.

    What he actually wrote was:

    BEGIN QUOTE
    void somefunc(void){
    /* bunch of stuff, including one too few "}" */
    }
    #endfunction
    END QUOTE

    My only quibble is that I'd put a space in front of the opening '{'.

    [...]

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, May 11, 2011
    #11
  12. David Mathog <> writes:
    > On May 10, 10:30 am, Ben Pfaff <> wrote:
    >> Try using another compiler or C parser.  GCC is excessively
    >> forgiving because it allows nested function definitions;

    >
    > Ah, so that's why it goes on so long. So I can get a similar result
    > with:
    >
    > -fno-nested-functions
    >
    > Might as well add that, as I don't think I have ever intentionally
    > used a nested function.


    As far as I can tell, gcc has no "-fno-nested-functions" option.

    You can disable nested functions using, for example, "-ansi
    -pedantic" or "-std=c99 -pedantic", but that's probably not going to
    change how the source code is parsed, and therefore won't help with
    the cascade of errors resulting from a syntax error. More generally,
    compilers that have extensions that extend the language grammar are
    likely, when the extensions are disabled, to use the same grammar
    but explicitly diagnose any uses of the extensions.

    As I wrote elsethread, your best bet is probably just to ignore
    everything after the first syntax error message, then fix the syntax
    error and compile again.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, May 11, 2011
    #12
  13. Ian Collins <> writes:
    > On 05/11/11 09:22 AM, Seebs wrote:
    >> On 2011-05-10, Kleuskes& Moos<> wrote:
    >>
    >>> And don't try to tell me that whitespace costs money, since that's
    >>> only valid on paper.

    >>
    >> It's not money, it's visual real estate. I can only see so many lines
    >> at a time. Seeing a few more lines of code at a time is a pretty noticeable
    >> payoff.

    >
    > I can see 112 lines with the large font I use, but I doubt I can parse
    > them all at once. I add whitespace and braces to break the code up into
    > visually distinct blocks. When I could only see a fraction the number
    > of lines (despite better eyesight!), I wrote denser code.
    >
    > Displays have improved beyond recognition in the last 20 years and
    > coding styles should adapt to suit.


    Personally, I don't use the K&R brace style because it's denser
    than the alternatives. I use it because I find it easy to read,
    and because I *like* it -- which is probably largely because it's
    what I first learned. If K&R had put opening and closing braces
    on their own lines, I'd probably argue in favor of that.

    On the other hand, any code I write for $JOB follows the current
    coding conventions. In some cases I dislike them (they vary over
    time and with different languages), but the only thing worse than
    a style I dislike would be a style I dislike mixed with K&R style.

    (One of the styles I've had to use is:
    if ( condition )
    {
    statement;
    statement;
    }
    )

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, May 11, 2011
    #13
  14. David Mathog

    Seebs Guest

    On 2011-05-10, Kleuskes & Moos <> wrote:
    > True. It's also very handy to be able to easily spot where you went
    > wrong, especially with important language elements such as braces. If
    > you think otherwise, feel free to do it otherwise.


    Oh, I totally agree that it is very handy. I just find that I don't
    have any more trouble with it in 1TBS than I do in others, and indeed,
    I tend to have less because it's more likely that both braces are on
    screen. :)

    > After years of contemplating the matter, i arrived at the conclusion
    > that it is unwise to want as much information as possible on your
    > screen. What you want is the _right_ information, and to be able to
    > spot it quickly.


    Agreed.

    I just find that braces are not enough information to be on lines; consistent
    1TBS works and does not appear to induce any mismatched-brace issues. I'd
    rather see what I'm interested in than a lot of braces I'm not.

    -s
    --
    Copyright 2011, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
    Seebs, May 11, 2011
    #14
  15. David Mathog

    Ben Pfaff Guest

    Keith Thompson <> writes:

    > As I wrote elsethread, your best bet is probably just to ignore
    > everything after the first syntax error message, then fix the syntax
    > error and compile again.


    That doesn't help with the OP's problem. Try compiling the
    following with GCC, without any compiler options:

    int a(void)
    {
    return 1;

    int b(void)
    {
    return 2;
    }

    int c(void)
    {
    return 3;
    }

    The only diagnostic is this:

    tmp.c: In function ‘a’:
    tmp.c:13: error: expected declaration or statement at end of input

    As the OP said, the location of the error is far removed from the
    actual problem, a missing } at the end of a().
    --
    "To get the best out of this book, I strongly recommend that you read it."
    --Richard Heathfield
    Ben Pfaff, May 11, 2011
    #15
  16. David Mathog

    Ben Pfaff Guest

    Ian Collins <> writes:

    > Displays have improved beyond recognition in the last 20 years and
    > coding styles should adapt to suit.


    Displays have started shrinking vertically, though. Most new
    screens are 16:9 instead of the former standard 4:3. That's
    fewer lines of code displayed vertically for a given amount of
    screen area.
    --
    "Large amounts of money tend to quench any scruples I might be having."
    -- Stephan Wilms
    Ben Pfaff, May 11, 2011
    #16
  17. David Mathog

    Ian Collins Guest

    On 05/11/11 04:09 PM, Ben Pfaff wrote:
    > Ian Collins<> writes:
    >
    >> Displays have improved beyond recognition in the last 20 years and
    >> coding styles should adapt to suit.

    >
    > Displays have started shrinking vertically, though. Most new
    > screens are 16:9 instead of the former standard 4:3. That's
    > fewer lines of code displayed vertically for a given amount of
    > screen area.


    Below 24" yes (with a few exceptions). But decent sized (24" 16:10 and
    above) still have plenty of vertical pixels.

    --
    Ian Collins
    Ian Collins, May 11, 2011
    #17
  18. David Mathog

    Ben Pfaff Guest

    Ian Collins <> writes:

    > On 05/11/11 04:09 PM, Ben Pfaff wrote:
    >> Ian Collins<> writes:
    >>
    >>> Displays have improved beyond recognition in the last 20 years and
    >>> coding styles should adapt to suit.

    >>
    >> Displays have started shrinking vertically, though. Most new
    >> screens are 16:9 instead of the former standard 4:3. That's
    >> fewer lines of code displayed vertically for a given amount of
    >> screen area.

    >
    > Below 24" yes (with a few exceptions). But decent sized (24" 16:10
    > and above) still have plenty of vertical pixels.


    It's hard on me, though, because I prefer small laptops. My
    previous 12" laptop with a 4:3 screen more easily accommodated
    lots of code than my current 13.3" laptop with a 16:9 screen.

    At this rate, my next laptop will have a 2:1 screen.
    --
    Ben Pfaff
    http://benpfaff.org
    Ben Pfaff, May 11, 2011
    #18
  19. David Mathog

    Ian Collins Guest

    On 05/11/11 04:19 PM, Ben Pfaff wrote:
    > Ian Collins<> writes:
    >
    >> On 05/11/11 04:09 PM, Ben Pfaff wrote:
    >>> Ian Collins<> writes:
    >>>
    >>>> Displays have improved beyond recognition in the last 20 years and
    >>>> coding styles should adapt to suit.
    >>>
    >>> Displays have started shrinking vertically, though. Most new
    >>> screens are 16:9 instead of the former standard 4:3. That's
    >>> fewer lines of code displayed vertically for a given amount of
    >>> screen area.

    >>
    >> Below 24" yes (with a few exceptions). But decent sized (24" 16:10
    >> and above) still have plenty of vertical pixels.

    >
    > It's hard on me, though, because I prefer small laptops. My
    > previous 12" laptop with a 4:3 screen more easily accommodated
    > lots of code than my current 13.3" laptop with a 16:9 screen.
    >
    > At this rate, my next laptop will have a 2:1 screen.


    :)

    It is a pain, but laptop designers tend to target DVD/BD players rather
    than programmers these days. My old Dell had a 15" 1600x1200 display, a
    real coder's laptop. Sadly it fell victim to our latest earthquake,
    along with the fish tank that landed on it!

    --
    Ian Collins
    Ian Collins, May 11, 2011
    #19
  20. David Mathog

    Seebs Guest

    On 2011-05-11, Ian Collins <> wrote:
    > Below 24" yes (with a few exceptions). But decent sized (24" 16:10 and
    > above) still have plenty of vertical pixels.


    Even with vertical pixels, I don't do windows with lots more lines, I do
    windows with up to about 30 lines and then pick larger fonts so I can
    see better. :)

    -s
    --
    Copyright 2011, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
    Seebs, May 11, 2011
    #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. Vlajko Knezic
    Replies:
    1
    Views:
    10,605
    Joe Smith
    Mar 6, 2005
  2. Miguel Dias Moura
    Replies:
    0
    Views:
    347
    Miguel Dias Moura
    May 24, 2004
  3. =?Utf-8?B?Sm9obiBCYWlsZXk=?=

    Can you still indicate to distribute files locally in ASP.Net 2.0

    =?Utf-8?B?Sm9obiBCYWlsZXk=?=, Jun 16, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    348
    =?Utf-8?B?Sm9obiBCYWlsZXk=?=
    Jun 16, 2005
  4. Niclas

    validation - indicate invalid field

    Niclas, Apr 2, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    376
    =?Utf-8?B?UGhpbGxpcCBXaWxsaWFtcw==?=
    Apr 2, 2006
  5. ABC
    Replies:
    1
    Views:
    1,968
    Kevin Spencer
    Apr 22, 2006
Loading...

Share This Page