Size of bool unspecified: why?

Discussion in 'C++' started by MikeP, Jul 16, 2011.

  1. MikeP

    MikeP Guest

    Why is the size of 'bool' unspecified? That makes bools pretty useless as
    struct members. If one foregoes bools in structs, why not then specify
    that bools should be the size of int and thereby likely to be fast to
    pass to and from functions? (Is it less efficient to pass
    less-than-word-size integers because then they have to be sign-extended
    or zero-extended, or any other reason?)
     
    MikeP, Jul 16, 2011
    #1
    1. Advertising

  2. MikeP

    MikeP Guest

    Robert Wessel wrote:
    > On Sat, 16 Jul 2011 05:33:22 -0500, "MikeP" <> wrote:
    >
    >> Why is the size of 'bool' unspecified? That makes bools pretty
    >> useless as struct members. If one foregoes bools in structs, why not
    >> then specify that bools should be the size of int and thereby likely
    >> to be fast to pass to and from functions? (Is it less efficient to
    >> pass less-than-word-size integers because then they have to be
    >> sign-extended or zero-extended, or any other reason?)

    >
    >
    > How does the unspecified size of bool make them useless in structs?


    How doesn't it?

    > The size of ints is also unspecified*, and I use ints in structures
    > all the time.


    Well, there are structs, and then there are structs.

    >
    > *except being at least 16 bits - although clearly a minimum exists for
    > bools as well.


    On VC++ 2010 it is one byte. In some version long ago, it was the size of
    int, but probably because that was before the standard declared it could
    be unspecified. Let's play a game ("Would you like to play a game? How
    about a nice game of chess?" ;) ). If you could have your bool and eat it
    too... let me rephrase that: if you could create your own boolean type,
    describe it. Describe 2 if you want to: one for C++, and one for your
    ideal language that does not yet exist.
     
    MikeP, Jul 17, 2011
    #2
    1. Advertising

  3. MikeP

    Ian Collins Guest

    On 07/17/11 05:07 PM, MikeP wrote:
    > Robert Wessel wrote:
    >> On Sat, 16 Jul 2011 05:33:22 -0500, "MikeP"<> wrote:
    >>
    >>> Why is the size of 'bool' unspecified? That makes bools pretty
    >>> useless as struct members. If one foregoes bools in structs, why not
    >>> then specify that bools should be the size of int and thereby likely
    >>> to be fast to pass to and from functions? (Is it less efficient to
    >>> pass less-than-word-size integers because then they have to be
    >>> sign-extended or zero-extended, or any other reason?)

    >>
    >>
    >> How does the unspecified size of bool make them useless in structs?

    >
    > How doesn't it?


    It's never bothered me. Why would the size be important? If size and
    alignment is important to an environment, the sizes will be specified.

    --
    Ian Collins
     
    Ian Collins, Jul 17, 2011
    #3
  4. MikeP

    MikeP Guest

    Ian Collins wrote:
    > On 07/17/11 05:07 PM, MikeP wrote:
    >> Robert Wessel wrote:
    >>> On Sat, 16 Jul 2011 05:33:22 -0500, "MikeP"<> wrote:
    >>>> Why is the size of 'bool' unspecified? That makes bools pretty
    >>>> useless as struct members. If one foregoes bools in structs, why
    >>>> not then specify that bools should be the size of int and thereby
    >>>> likely to be fast to pass to and from functions? (Is it less
    >>>> efficient to pass less-than-word-size integers because then they
    >>>> have to be sign-extended or zero-extended, or any other reason?)
    >>>
    >>>
    >>> How does the unspecified size of bool make them useless in structs?

    >>
    >> How doesn't it?

    >
    > It's never bothered me. Why would the size be important? If size and
    > alignment is important to an environment, the sizes will be specified.


    I'll return to your post after RW replies.
     
    MikeP, Jul 17, 2011
    #4
  5. MikeP

    MikeP Guest

    Robert Wessel wrote:
    [whatever the **** he said]

    I am not a warrior.

    Someone tell Eric C. Weis to GET THE **** OUT OF MY FACE.


    > On Sun, 17 Jul 2011 00:07:19 -0500, "MikeP" <> wrote:
    >
    >> Robert Wessel wrote:
    >>> On Sat, 16 Jul 2011 05:33:22 -0500, "MikeP" <>
    >>> wrote:
    >>>
    >>>> Why is the size of 'bool' unspecified? That makes bools pretty
    >>>> useless as struct members. If one foregoes bools in structs, why
    >>>> not then specify that bools should be the size of int and thereby
    >>>> likely to be fast to pass to and from functions? (Is it less
    >>>> efficient to pass less-than-word-size integers because then they
    >>>> have to be sign-extended or zero-extended, or any other reason?)
    >>>
    >>>
    >>> How does the unspecified size of bool make them useless in structs?

    >>
    >> How doesn't it?
    >>
    >>> The size of ints is also unspecified*, and I use ints in structures
    >>> all the time.

    >
    >
    > I give up - how does it? I've used bools in structs. Seemed to work
    > just fine. I've used bit fields in structs too, and they're also
    > undefined as to what they're actually stored in. That also seemed to
    > work.
    >
    > Both of those, the size of bools, and the storage of bit fields, are
    > defined for a particular implementation.
    >
    >
    >> Well, there are structs, and then there are structs.

    >
    >
    > True, but less than informative. I personally find structs containing
    > long doubles to be particular impressive - now *those* are *structs*!
    >
    >
    >>>
    >>> *except being at least 16 bits - although clearly a minimum exists
    >>> for bools as well.

    >>
    >> On VC++ 2010 it is one byte. In some version long ago, it was the
    >> size of int, but probably because that was before the standard
    >> declared it could be unspecified. Let's play a game ("Would you like
    >> to play a game? How about a nice game of chess?" ;) ). If you could
    >> have your bool and eat it too... let me rephrase that: if you could
    >> create your own boolean type, describe it. Describe 2 if you want
    >> to: one for C++, and one for your ideal language that does not yet
    >> exist.

    >
    >
    > Are you talking about interfacing code compiled with different
    > versions of the compiler? As a general rule, you shouldn't be mixing
    > code from different versions of a C compiler (or equivalently,
    > invocations of the C compiler with certain different options), unless
    > you restrict yourself to things specified by the system ABI or some
    > other ABI that's specified to be valid between the versions in
    > question. There are plenty of potential (and allowed)
    > incompatibilities in that scenario. Everything from padding to
    > alignment, to the storage of bit fields, to the size of ints, to the
    > signedness of chars, to calling convention, to name decoration, to the
    > format of vtables, to...
    >
    > Errr... and my "ideal" boolean stores one of two values, and I care
    > little about its internal representation. I'd probably pick something
    > the size of an int (or whatever my languages equivalent for that is)
    > if I cared about speed, a byte or a bit if I cared more about space.
    >
    > And I really don't mind if you reply to Ian before I reply to you.
    > Really I don't.
     
    MikeP, Jul 17, 2011
    #5
  6. MikeP

    MikeP Guest

    Robert Wessel wrote:

    I meant PUH LEEEEZE! (And go fuk yer mom).
     
    MikeP, Jul 17, 2011
    #6
  7. MikeP

    MikeP Guest

    Robert Wessel wrote:
    > On Sun, 17 Jul 2011 03:02:15 -0500, "MikeP" <> wrote:
    >
    >> Robert Wessel wrote:
    >> [whatever the **** he said]
    >>
    >> I am not a warrior.
    >>
    >> Someone tell Eric C. Weis to GET THE **** OUT OF MY FACE.

    >
    >
    > Please don't top-post.
    >
    >
    >>> On Sun, 17 Jul 2011 00:07:19 -0500, "MikeP" <>
    >>> wrote:
    >>>
    >>>> Robert Wessel wrote:
    >>>>> On Sat, 16 Jul 2011 05:33:22 -0500, "MikeP" <>
    >>>>> wrote:
    >>>>>
    >>>>>> Why is the size of 'bool' unspecified? That makes bools pretty
    >>>>>> useless as struct members. If one foregoes bools in structs, why
    >>>>>> not then specify that bools should be the size of int and thereby
    >>>>>> likely to be fast to pass to and from functions? (Is it less
    >>>>>> efficient to pass less-than-word-size integers because then they
    >>>>>> have to be sign-extended or zero-extended, or any other reason?)
    >>>>>
    >>>>>
    >>>>> How does the unspecified size of bool make them useless in
    >>>>> structs?
    >>>>
    >>>> How doesn't it?
    >>>>
    >>>>> The size of ints is also unspecified*, and I use ints in
    >>>>> structures all the time.
    >>>
    >>>
    >>> I give up - how does it? I've used bools in structs. Seemed to
    >>> work just fine. I've used bit fields in structs too, and they're
    >>> also undefined as to what they're actually stored in. That also
    >>> seemed to work.
    >>>
    >>> Both of those, the size of bools, and the storage of bit fields, are
    >>> defined for a particular implementation.
    >>>
    >>>
    >>>> Well, there are structs, and then there are structs.
    >>>
    >>>
    >>> True, but less than informative. I personally find structs
    >>> containing long doubles to be particular impressive - now *those*
    >>> are *structs*!
    >>>
    >>>
    >>>>>
    >>>>> *except being at least 16 bits - although clearly a minimum exists
    >>>>> for bools as well.
    >>>>
    >>>> On VC++ 2010 it is one byte. In some version long ago, it was the
    >>>> size of int, but probably because that was before the standard
    >>>> declared it could be unspecified. Let's play a game ("Would you
    >>>> like to play a game? How about a nice game of chess?" ;) ). If you
    >>>> could have your bool and eat it too... let me rephrase that: if
    >>>> you could create your own boolean type, describe it. Describe 2 if
    >>>> you want to: one for C++, and one for your ideal language that
    >>>> does not yet exist.
    >>>
    >>>
    >>> Are you talking about interfacing code compiled with different
    >>> versions of the compiler? As a general rule, you shouldn't be
    >>> mixing code from different versions of a C compiler (or
    >>> equivalently, invocations of the C compiler with certain different
    >>> options), unless you restrict yourself to things specified by the
    >>> system ABI or some other ABI that's specified to be valid between
    >>> the versions in question. There are plenty of potential (and
    >>> allowed) incompatibilities in that scenario. Everything from
    >>> padding to alignment, to the storage of bit fields, to the size of
    >>> ints, to the signedness of chars, to calling convention, to name
    >>> decoration, to the format of vtables, to...
    >>>
    >>> Errr... and my "ideal" boolean stores one of two values, and I care
    >>> little about its internal representation. I'd probably pick
    >>> something the size of an int (or whatever my languages equivalent
    >>> for that is) if I cared about speed, a byte or a bit if I cared
    >>> more about space.
    >>>
    >>> And I really don't mind if you reply to Ian before I reply to you.
    >>> Really I don't.


    And why don't you get the **** out of my face?
     
    MikeP, Jul 17, 2011
    #7
  8. MikeP <> wrote:
    > Why is the size of 'bool' unspecified?


    Probably for the same reason that the size of *any* basic type (with
    the exception of char) is unspecified?
     
    Juha Nieminen, Jul 17, 2011
    #8
  9. MikeP

    James Guest

    "MikeP" <> wrote in message
    news:ivue3c$fp4$...
    >> Robert Wessel wrote:
    >> On Sun, 17 Jul 2011 03:02:15 -0500, "MikeP" <> wrote:

    [...]
    >
    > And why don't you get the **** out of my face?


    Are you really that moronic?

    Wow! :^)
     
    James, Jul 18, 2011
    #9
  10. MikeP

    MikeP Guest

    James wrote:
    > "MikeP" <> wrote in message
    > news:ivue3c$fp4$...
    >>> Robert Wessel wrote:
    >>> On Sun, 17 Jul 2011 03:02:15 -0500, "MikeP" <>
    >>> wrote: [...]

    >>
    >> And why don't you get the **** out of my face?

    >
    > Are you really that moronic?
    >
    > Wow! :^)


    I have my moments\
     
    MikeP, Jul 18, 2011
    #10
  11. MikeP

    MikeP Guest

    Juha Nieminen wrote:
    > MikeP <> wrote:
    >> Why is the size of 'bool' unspecified?

    >
    > Probably for the same reason that the size of *any* basic type (with
    > the exception of char) is unspecified?'


    So the answer would then be adolescent stupidity\
     
    MikeP, Jul 18, 2011
    #11
  12. MikeP

    James Guest

    "MikeP" <> wrote in message
    news:j016je$7s1$...
    > James wrote:
    >> "MikeP" <> wrote in message
    >> news:ivue3c$fp4$...
    >>>> Robert Wessel wrote:
    >>>> On Sun, 17 Jul 2011 03:02:15 -0500, "MikeP" <>
    >>>> wrote: [...]
    >>>
    >>> And why don't you get the **** out of my face?

    >>
    >> Are you really that moronic?
    >>
    >> Wow! :^)

    >
    > I have my moments\


    ;^)
     
    James, Jul 19, 2011
    #12
  13. MikeP

    Ian Collins Guest

    On 07/18/11 11:49 PM, MikeP wrote:
    > James wrote:
    >>
    >> Are you really that moronic?
    >>
    >> Wow! :^)

    >
    > I have my moments\


    Some moments are best enjoyed in private.

    --
    Ian Collins
     
    Ian Collins, Jul 19, 2011
    #13
  14. MikeP

    MikeP Guest

    Ian Collins wrote:
    > On 07/18/11 11:49 PM, MikeP wrote:
    >> James wrote:
    >>>
    >>> Are you really that moronic?
    >>>
    >>> Wow! :^)

    >>
    >> I have my moments\

    >
    > Some moments are best enjoyed in private.


    When one Mr. John Daniels invites you to have a few, well, he can be
    quite influential (hard to say no to a friend that has always been there
    for you), especially if the bars closed way to early (3 AM?). Anyway, I
    didn't type that (John did, and he probably thought it would be absurdly
    funny too, who knows).
     
    MikeP, Jul 20, 2011
    #14
  15. MikeP

    James Kanze Guest

    On Jul 16, 6:02 pm, BGB <> wrote:
    > On 7/16/2011 3:33 AM, MikeP wrote:


    > > Why is the size of 'bool' unspecified? That makes bools pretty useless as
    > > struct members. If one foregoes bools in structs, why not then specify
    > > that bools should be the size of int and thereby likely to be fast to
    > > pass to and from functions? (Is it less efficient to pass
    > > less-than-word-size integers because then they have to be sign-extended
    > > or zero-extended, or any other reason?)


    First, is size of bool unspecified? Or just implementation
    defined? The size of all types is implementation defined (with
    a minimum size).

    And I don't see the issue with regards to structs.

    > IIRC, many compilers default to making them the same size as char, or a
    > single byte. this tends to be most convinient as, bigger, and they are
    > just wasting space, and smaller, as messing with bits is awkward and
    > costly (as well as compromising their direct addressability, ...).


    A bool is required to be addressable; sizeof(bool) is also
    required to return an integral value. So a bool can't be
    smaller than a char. On a byte addressable machine, there's
    also no reason to make them bigger, and I would expect them to
    usually be the same as a char. On a word addressable machine,
    accessing single bytes may be more expensive than accessing a
    complete word, and there are arguments both ways.

    > as for passing smaller integer types, these tend to be promoted
    > internally to the smallest convinient size (namely, int) anyways, and on
    > common architectures this doesn't add any real cost (both x86 and ARM
    > have instructions to load a byte from memory with sign or zero extension).


    Depending on the context: on many machines, it may be just as
    fast to simply pass an int, with garbage in all but the low/high
    order byte (depending on endianness). The garbage doesn't
    matter, of course, because the callee won't ever look at it.

    > granted, yes, this does in-fact still depend on the compiler
    > though.


    As does just about everything else.

    --
    James Kanze
     
    James Kanze, Jul 20, 2011
    #15
  16. MikeP

    James Kanze Guest

    On Jul 18, 12:50 pm, "MikeP" <> wrote:
    > Juha Nieminen wrote:
    > > MikeP <> wrote:
    > >> Why is the size of 'bool' unspecified?


    > > Probably for the same reason that the size of *any* basic type (with
    > > the exception of char) is unspecified?'


    > So the answer would then be adolescent stupidity\


    Or enough maturity to recognize that not all machines are PC's.

    --
    James Kanze
     
    James Kanze, Jul 20, 2011
    #16
  17. MikeP

    JBarleycorn Guest

    James Kanze wrote:
    > On Jul 16, 6:02 pm, BGB <> wrote:
    >> On 7/16/2011 3:33 AM, MikeP wrote:

    >
    >>> Why is the size of 'bool' unspecified? That makes bools pretty
    >>> useless as struct members. If one foregoes bools in structs, why
    >>> not then specify that bools should be the size of int and thereby
    >>> likely to be fast to pass to and from functions? (Is it less
    >>> efficient to pass less-than-word-size integers because then they
    >>> have to be sign-extended or zero-extended, or any other reason?)

    >
    > First, is size of bool unspecified? Or just implementation
    > defined?


    Isn't that the same thing?

    > The size of all types is implementation defined (with
    > a minimum size).
    >
    > And I don't see the issue with regards to structs.


    C compatibility where layout, then, matters? Data transfer/storage.

    >
    >> IIRC, many compilers default to making them the same size as char,
    >> or a single byte. this tends to be most convinient as, bigger, and
    >> they are just wasting space, and smaller, as messing with bits is
    >> awkward and costly (as well as compromising their direct
    >> addressability, ...).

    >
    > A bool is required to be addressable; sizeof(bool) is also
    > required to return an integral value. So a bool can't be
    > smaller than a char. On a byte addressable machine, there's
    > also no reason to make them bigger,


    Efficiency?

    > and I would expect them to
    > usually be the same as a char. On a word addressable machine,
    > accessing single bytes may be more expensive than accessing a
    > complete word, and there are arguments both ways.


    See, efficiency.

    >
    >> as for passing smaller integer types, these tend to be promoted
    >> internally to the smallest convinient size (namely, int) anyways,


    Right, but a type that need not be promoted does not need that extra
    step.

    >> and on common architectures this doesn't add any real cost (both x86
    >> and ARM have instructions to load a byte from memory with sign or
    >> zero extension).

    >
    > Depending on the context: on many machines, it may be just as
    > fast to simply pass an int, with garbage in all but the low/high
    > order byte (depending on endianness).


    But compilers probably don't do that.

    > The garbage doesn't
    > matter, of course, because the callee won't ever look at it.
    >
    >> granted, yes, this does in-fact still depend on the compiler
    >> though.

    >
    > As does just about everything else.


    What is common practice though is the real concern because just about
    everything in C++ is platform-dependent.
     
    JBarleycorn, Jul 20, 2011
    #17
  18. MikeP

    Ian Collins Guest

    On 07/21/11 08:46 AM, JBarleycorn wrote:
    > James Kanze wrote:
    >> On Jul 16, 6:02 pm, BGB<> wrote:
    >>> On 7/16/2011 3:33 AM, MikeP wrote:

    >>
    >>>> Why is the size of 'bool' unspecified? That makes bools pretty
    >>>> useless as struct members. If one foregoes bools in structs, why
    >>>> not then specify that bools should be the size of int and thereby
    >>>> likely to be fast to pass to and from functions? (Is it less
    >>>> efficient to pass less-than-word-size integers because then they
    >>>> have to be sign-extended or zero-extended, or any other reason?)

    >>
    >> First, is size of bool unspecified? Or just implementation
    >> defined?

    >
    > Isn't that the same thing?


    Not in terms of the standard. Implementation defined things have to be
    defined by the implementation.

    >> The size of all types is implementation defined (with
    >> a minimum size).
    >>
    >> And I don't see the issue with regards to structs.

    >
    > C compatibility where layout, then, matters? Data transfer/storage.


    Then C++ added bool, C didn't have it so there was no layout
    compatibility to maintain.

    >>> IIRC, many compilers default to making them the same size as char,
    >>> or a single byte. this tends to be most convinient as, bigger, and
    >>> they are just wasting space, and smaller, as messing with bits is
    >>> awkward and costly (as well as compromising their direct
    >>> addressability, ...).

    >>
    >> A bool is required to be addressable; sizeof(bool) is also
    >> required to return an integral value. So a bool can't be
    >> smaller than a char. On a byte addressable machine, there's
    >> also no reason to make them bigger,

    >
    > Efficiency?


    Maybe, but efficiency isn't only dependent on size. If it were, we'd be
    using 64 bit ints on 64 bit machines.

    --
    Ian Collins
     
    Ian Collins, Jul 20, 2011
    #18
  19. MikeP

    Noah Roberts Guest

    On 7/20/2011 1:46 PM, JBarleycorn wrote:
    > James Kanze wrote:
    >> On Jul 16, 6:02 pm, BGB<> wrote:
    >>> On 7/16/2011 3:33 AM, MikeP wrote:

    >>
    >>>> Why is the size of 'bool' unspecified? That makes bools pretty
    >>>> useless as struct members. If one foregoes bools in structs, why
    >>>> not then specify that bools should be the size of int and thereby
    >>>> likely to be fast to pass to and from functions? (Is it less
    >>>> efficient to pass less-than-word-size integers because then they
    >>>> have to be sign-extended or zero-extended, or any other reason?)

    >>
    >> First, is size of bool unspecified? Or just implementation
    >> defined?

    >
    > Isn't that the same thing?


    Implementation defined has to be documented, unspecified does not. Both
    are behaviors defined by the implementation.
     
    Noah Roberts, Jul 21, 2011
    #19
  20. MikeP

    JBarleycorn Guest

    "Ian Collins" <> wrote in message
    news:...
    > On 07/21/11 08:46 AM, JBarleycorn wrote:
    >> James Kanze wrote:
    >>> On Jul 16, 6:02 pm, BGB<> wrote:
    >>>> On 7/16/2011 3:33 AM, MikeP wrote:
    >>>
    >>>>> Why is the size of 'bool' unspecified? That makes bools pretty
    >>>>> useless as struct members. If one foregoes bools in structs, why
    >>>>> not then specify that bools should be the size of int and thereby
    >>>>> likely to be fast to pass to and from functions? (Is it less
    >>>>> efficient to pass less-than-word-size integers because then they
    >>>>> have to be sign-extended or zero-extended, or any other reason?)
    >>>
    >>> First, is size of bool unspecified? Or just implementation
    >>> defined?

    >>
    >> Isn't that the same thing?

    >
    > Not in terms of the standard. Implementation defined things have to be
    > defined by the implementation.


    Why is "unspecified" necessary? Does anyone think that not specifying the
    size of a bool is a good thing?

    How can bools be used in structs if every implementation can define it
    differently?

    >
    >>> The size of all types is implementation defined (with
    >>> a minimum size).
    >>>
    >>> And I don't see the issue with regards to structs.

    >>
    >> C compatibility where layout, then, matters? Data transfer/storage.

    >
    > Then C++ added bool, C didn't have it so there was no layout
    > compatibility to maintain.


    Oh yeah! The 2 groups should have coordinated the introduction of bool.

    >
    >>>> IIRC, many compilers default to making them the same size as char,
    >>>> or a single byte. this tends to be most convinient as, bigger, and
    >>>> they are just wasting space, and smaller, as messing with bits is
    >>>> awkward and costly (as well as compromising their direct
    >>>> addressability, ...).
    >>>
    >>> A bool is required to be addressable; sizeof(bool) is also
    >>> required to return an integral value. So a bool can't be
    >>> smaller than a char. On a byte addressable machine, there's
    >>> also no reason to make them bigger,

    >>
    >> Efficiency?

    >
    > Maybe, but efficiency isn't only dependent on size. If it were, we'd
    > be using 64 bit ints on 64 bit machines.
    >


    I meant efficient in time, not space. Are not 64-bit ints indeed more
    efficient (in time) than 32-bit ints, say on x86 vs. x64? Anyone have a
    good simple test for this? Probably at least 3 things need to be eval'd:
    argument passing performance, return value performance, arithmetic
    performance. I can compare the 8-bit bool vs. a 32-bit int on my machine,
    but I don't have a 64-bit machine.
     
    JBarleycorn, Jul 21, 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. SPG
    Replies:
    1
    Views:
    1,254
    Rogan Dawes
    Jul 28, 2004
  2. Christopher Benson-Manica

    Pointer to array of unspecified size

    Christopher Benson-Manica, Nov 26, 2003, in forum: C Programming
    Replies:
    14
    Views:
    622
    Dan Pop
    Dec 2, 2003
  3. Bertrand Geston
    Replies:
    1
    Views:
    372
    Bertel Lund Hansen
    Aug 31, 2003
  4. Ulrich Petri
    Replies:
    7
    Views:
    5,293
    Ulrich Petri
    Sep 1, 2003
  5. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,221
    Smokey Grindel
    Dec 2, 2006
Loading...

Share This Page