FAQ issue: Guaranteed value ranges of fundamental types?

Discussion in 'C Programming' started by Alf P. Steinbach, Feb 5, 2005.

  1. The C++ FAQ item 29.5 (this seems to be strongly related to C), at
    <url: http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.5>
    mentions that

    <quote>
    C++ guarantees a char is exactly one byte which is at least 8 bits, short
    is at least 16 bits, int is at least 16 bits, and long is at least 32
    bits.
    </quote>


    Questions:

    (1) This guarantee seems to come from the C standard. Which I don't
    have. Does the C++ standard really guarantee this?

    (2) Is this guarantee originally formulated in terms of number of bits,
    or in terms of e.g. decimal value ranges?

    (3) Concerning (2), if formulated in terms of number of bits, are the number
    of bits mentioned simply sizeof(T)*CHAR_BIT, which doesn't say much about
    value ranges, or are they stated to be the value representation bits?


    (Intentionally cross-posted [comp.lang.c++] and [comp.lang.c]).

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Feb 5, 2005
    #1
    1. Advertising

  2. Alf P. Steinbach

    pete Guest

    Alf P. Steinbach wrote:
    >
    > The C++ FAQ item 29.5 (this seems to be strongly related to C), at
    > <url: http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.5>
    > mentions that
    >
    > <quote>
    > C++ guarantees a char is exactly
    > one byte which is at least 8 bits, short
    > is at least 16 bits, int is at least 16 bits,
    > and long is at least 32 bits.
    > </quote>
    >
    > Questions:
    >
    > (1) This guarantee seems to come from the C standard. Which I don't
    > have. Does the C++ standard really guarantee this?
    >
    > (2) Is this guarantee originally
    > formulated in terms of number of bits,
    > or in terms of e.g. decimal value ranges?


    The part of the C standard which is called
    "Sizes of integral types" in C89 and
    "Sizes of integer types" in C99,
    is specified in terms of ranges.

    C99 describes padding bits for integer types.

    --
    pete
     
    pete, Feb 5, 2005
    #2
    1. Advertising

  3. Alf P. Steinbach

    CBFalconer Guest

    "Alf P. Steinbach" wrote:
    >
    > The C++ FAQ item 29.5 (this seems to be strongly related to C), at
    > <url: http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.5>
    > mentions that
    >
    > <quote>
    > C++ guarantees a char is exactly one byte which is at least 8
    > bits, short is at least 16 bits, int is at least 16 bits, and
    > long is at least 32 bits.
    > </quote>
    >
    > Questions:
    >
    > (1) This guarantee seems to come from the C standard. Which I
    > don't have. Does the C++ standard really guarantee this?


    I dunno. This is c.l.c. Google for N869 to get the last draft of
    the C standard. f'ups set, which you should have done in the
    original posting.

    >
    > (2) Is this guarantee originally formulated in terms of number of
    > bits, or in terms of e.g. decimal value ranges?


    By values. Other specifications translate that into viable bits.

    >
    > (3) Concerning (2), if formulated in terms of number of bits, are
    > the number of bits mentioned simply sizeof(T)*CHAR_BIT, which
    > doesn't say much about value ranges, or are they stated to be
    > the value representation bits?


    No, because there may be bits for other purposes, such as trap
    values.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
     
    CBFalconer, Feb 5, 2005
    #3
  4. * CBFalconer:
    > "Alf P. Steinbach" wrote:
    > >
    > > The C++ FAQ item 29.5 (this seems to be strongly related to C), at
    > > <url: http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.5>
    > > mentions that
    > >
    > > <quote>
    > > C++ guarantees a char is exactly one byte which is at least 8
    > > bits, short is at least 16 bits, int is at least 16 bits, and
    > > long is at least 32 bits.
    > > </quote>
    > >
    > > Questions:
    > >
    > > (1) This guarantee seems to come from the C standard. Which I
    > > don't have. Does the C++ standard really guarantee this?

    >
    > I dunno. This is c.l.c. Google for N869 to get the last draft of
    > the C standard. f'ups set, which you should have done in the
    > original posting.


    It was intentionally cross-posted; F.U.T. overridden. :)

    Thanks for the "N869" reference.

    Yes, the C standard specifies those minimum ranges in the documentation
    of [limits.h], which the C++ standard refers to the C standard for.


    > > (2) Is this guarantee originally formulated in terms of number of
    > > bits, or in terms of e.g. decimal value ranges?

    >
    > By values. Other specifications translate that into viable bits.


    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Feb 5, 2005
    #4
  5. Alf P. Steinbach wrote:

    > The C++ FAQ item 29.5 (this seems to be strongly related to C), at
    > <url: http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.5>
    > mentions that
    >
    > <quote>
    > C++ guarantees a char is exactly one byte which is at least 8 bits, short
    > is at least 16 bits, int is at least 16 bits, and long is at least 32
    > bits.
    > </quote>
    >
    >
    > Questions:
    >
    > (1) This guarantee seems to come from the C standard. Which I don't
    > have. Does the C++ standard really guarantee this?



    Yes. Also, except where otherwise is stated, C90 is a subset of C++98
    standard.



    > (2) Is this guarantee originally formulated in terms of number of bits,
    > or in terms of e.g. decimal value ranges?



    Decimal ranges. C90 defines the following (from the last C90 draft):


    "Sizes of integral types <limits.h>

    The values given below shall be replaced by constant expressions
    suitable for use in #if preprocessing directives. Their
    implementation-defined values shall be equal or greater in magnitude
    (absolute value) to those shown, with the same sign.

    * maximum number of bits for smallest object that is not a bit-field
    (byte)
    CHAR_BIT 8

    * minimum value for an object of type signed char
    SCHAR_MIN -127

    * maximum value for an object of type signed char
    SCHAR_MAX +127

    * maximum value for an object of type unsigned char
    UCHAR_MAX 255

    * minimum value for an object of type char
    CHAR_MIN see below

    * maximum value for an object of type char
    CHAR_MAX see below

    * maximum number of bytes in a multibyte character, for any
    supported locale
    MB_LEN_MAX 1

    * minimum value for an object of type short int
    SHRT_MIN -32767

    * maximum value for an object of type short int
    SHRT_MAX +32767

    * maximum value for an object of type unsigned short int
    USHRT_MAX 65535

    * minimum value for an object of type int
    INT_MIN -32767

    * maximum value for an object of type int
    INT_MAX +32767

    * maximum value for an object of type unsigned int
    UINT_MAX 65535

    * minimum value for an object of type long int
    LONG_MIN -2147483647

    * maximum value for an object of type long int
    LONG_MAX +2147483647

    * maximum value for an object of type unsigned long int
    ULONG_MAX 4294967295


    If the value of an object of type char sign-extends when used in
    an expression, the value of CHAR_MIN shall be the same as that of
    SCHAR_MIN and the value of CHAR_MAX shall be the same as that of
    SCHAR_MAX . If the value of an object of type char does not sign-extend
    when used in an expression, the value of CHAR_MIN shall be 0 and the
    value of CHAR_MAX shall be the same as that of UCHAR_MAX./7/"




    > (3) Concerning (2), if formulated in terms of number of bits, are the number
    > of bits mentioned simply sizeof(T)*CHAR_BIT, which doesn't say much about
    > value ranges, or are they stated to be the value representation bits?



    Apart from char, and unsigned char that are guaranteed to not have
    padding bits (anyone may tell about signed char?), the number of bits
    of a type may contain padding bits etc.




    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Feb 5, 2005
    #5
  6. Alf P. Steinbach wrote:
    [snip]
    > short is at least 16 bits, int is at least 16 bits, and long
    > is at least 32 bits.
    > </quote>


    That is contrary to what my copy of the standard says (see 3.9.1/1). It
    basically says that char <= short <= int <= long (i.e. there is no
    guarantee that a long is any bigger than a char, although there probably
    is no platform where sizeof(long) == sizeof(char)). For more information
    see 5.3.3 and 1.7..

    Regards,

    --
    Andreas Huber

    When replying by private email, please remove the words spam and trap
    from the address shown in the header.
     
    Andreas Huber, Feb 5, 2005
    #6
  7. "Andreas Huber" <> wrote...
    > Alf P. Steinbach wrote:
    > [snip]
    >> short is at least 16 bits, int is at least 16 bits, and long
    >> is at least 32 bits.
    >> </quote>

    >
    > That is contrary to what my copy of the standard says (see 3.9.1/1). It
    > basically says that char <= short <= int <= long (i.e. there is no


    I wonder what _exactly_ does your copy say in 3.9.1/1 that makes you
    derive that 'char <= short <= int'. But that doesn't matter. You are
    actually correct, the C standard defined those relationships between
    type sizes. It is true that char <= short <= int. It does not, however,
    mean that there is no guarantee that 'int' is larger than 'char'. The
    same C90 Standard when describing <limits.h> (and see 18.2.2/2 to know
    that C++ mandates the same values for all xx_MAX and xx_MIN values),
    does require *at least* ranges -32767..32767 for 'int' and -2^31..2^31
    for 'long'.

    > guarantee that a long is any bigger than a char, although there probably
    > is no platform where sizeof(long) == sizeof(char)). For more information
    > see 5.3.3 and 1.7..


    For more information see 18.2.2

    V
     
    Victor Bazarov, Feb 5, 2005
    #7
  8. Alf P. Steinbach

    infobahn Guest

    Victor Bazarov wrote:
    >
    > I wonder what _exactly_ does your copy say in 3.9.1/1 that makes you
    > derive that 'char <= short <= int'. But that doesn't matter. You are
    > actually correct, the C standard defined those relationships between
    > type sizes.


    C&V please.
     
    infobahn, Feb 5, 2005
    #8
  9. "infobahn" <> wrote...
    > Victor Bazarov wrote:
    >>
    >> I wonder what _exactly_ does your copy say in 3.9.1/1 that makes you
    >> derive that 'char <= short <= int'. But that doesn't matter. You are
    >> actually correct, the C standard defined those relationships between
    >> type sizes.

    >
    > C&V please.


    I don't have a copy of C90. I used to have a printed copy at work,
    but I don't work there any longer. I can be mistaken, therefore.

    V
     
    Victor Bazarov, Feb 5, 2005
    #9
  10. "Andreas Huber" <> writes:
    > Alf P. Steinbach wrote:
    > [snip]
    >> short is at least 16 bits, int is at least 16 bits, and long
    >> is at least 32 bits.
    >> </quote>

    >
    > That is contrary to what my copy of the standard says (see
    > 3.9.1/1). It basically says that char <= short <= int <= long
    > (i.e. there is no guarantee that a long is any bigger than a char,
    > although there probably is no platform where sizeof(long) ==
    > sizeof(char)). For more information see 5.3.3 and 1.7..


    There's no contradiction.

    The C standard guarantees that short and int are at least 16 bits, and
    long is at least 32 bits (it states these in terms of minimum ranges,
    but the requirement for a binary representation implies the sizes
    given). It also guarantees that int as at least as wide as short, and
    long is at least as wide as int. (Padding bits mean that this applies
    to the ranges, not the sizes.)

    I think the C++ standard has the same guarantees.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Feb 5, 2005
    #10
  11. Victor Bazarov wrote:
    > "Andreas Huber" <> wrote...
    >> Alf P. Steinbach wrote:
    >> [snip]
    >>> short is at least 16 bits, int is at least 16 bits, and long
    >>> is at least 32 bits.
    >>> </quote>

    >>
    >> That is contrary to what my copy of the standard says (see 3.9.1/1).
    >> It basically says that char <= short <= int <= long (i.e. there is no

    >
    > I wonder what _exactly_ does your copy say in 3.9.1/1 that makes you
    > derive that 'char <= short <= int'.


    I was wrong, it's actually 3.9.1/2...

    > But that doesn't matter. You are
    > actually correct, the C standard defined those relationships between
    > type sizes. It is true that char <= short <= int. It does not,
    > however, mean that there is no guarantee that 'int' is larger than
    > 'char'. The same C90 Standard when describing <limits.h> (and see
    > 18.2.2/2 to know that C++ mandates the same values for all xx_MAX and
    > xx_MIN values), does require *at least* ranges -32767..32767 for
    > 'int' and -2^31..2^31 for 'long'.
    >
    >> guarantee that a long is any bigger than a char, although there
    >> probably is no platform where sizeof(long) == sizeof(char)). For
    >> more information see 5.3.3 and 1.7..

    >
    > For more information see 18.2.2


    <blush> Ok, you got me on the left foot there. Although the C++ standard
    does not itself guarantee anything like that, it *refers* to C standard
    of which I don't even have a copy available... oh well.

    Thanks for clarifying.

    Regards,

    --
    Andreas Huber

    When replying by private email, please remove the words spam and trap
    from the address shown in the header.
     
    Andreas Huber, Feb 5, 2005
    #11
  12. Alf P. Steinbach

    CBFalconer Guest

    "Alf P. Steinbach" wrote:
    > CBFalconer:
    >> "Alf P. Steinbach" wrote:
    >>>

    .... snip ...
    >>>
    >>> (1) This guarantee seems to come from the C standard. Which I
    >>> don't have. Does the C++ standard really guarantee this?

    >>
    >> I dunno. This is c.l.c. Google for N869 to get the last draft of
    >> the C standard. f'ups set, which you should have done in the
    >> original posting.

    >
    > It was intentionally cross-posted; F.U.T. overridden. :)


    You got your inputs from c.l.c, now it should go away. That's why
    you should have set fups in the first place, and not have
    overridden mine. Notice I didn't object to the initial cross-post.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
     
    CBFalconer, Feb 5, 2005
    #12
  13. Alf P. Steinbach

    CBFalconer Guest

    Ioannis Vranos wrote:
    > Alf P. Steinbach wrote:
    >

    .... snip ...
    >>
    >> (1) This guarantee seems to come from the C standard. Which I
    >> don't have. Does the C++ standard really guarantee this?

    >
    > Yes. Also, except where otherwise is stated, C90 is a subset of
    > C++98 standard.


    See what happens when you don't set followups in the initial
    query. Misinformation like this works its way into c.l.c and is
    likely to produce an interminable stupid cross group argument.
    It's bad enough when the misinformation is native to the group.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
     
    CBFalconer, Feb 5, 2005
    #13
  14. Alf P. Steinbach

    Jack Klein Guest

    On Sat, 05 Feb 2005 13:11:04 GMT, (Alf P. Steinbach)
    wrote in comp.lang.c:

    > The C++ FAQ item 29.5 (this seems to be strongly related to C), at
    > <url: http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.5>
    > mentions that
    >
    > <quote>
    > C++ guarantees a char is exactly one byte which is at least 8 bits, short
    > is at least 16 bits, int is at least 16 bits, and long is at least 32
    > bits.
    > </quote>
    >
    >
    > Questions:
    >
    > (1) This guarantee seems to come from the C standard. Which I don't
    > have. Does the C++ standard really guarantee this?


    [snip]

    The fact that the C++ standard decided to cite the C standard as a
    normative reference is irrelevant here in comp.lang.c. The POSIX
    standard is also based on the C standard, but that doesn't make POSIX
    topical in comp.lang.c either.

    What the C++ language guarantees is 100% off-topic in c.l.c, period.
    The fact that the C++ standard does or does not refer to any or all
    parts of the C standard has no meaning at all in terms of C.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Feb 6, 2005
    #14
  15. * Jack Klein:
    > On Sat, 05 Feb 2005 13:11:04 GMT, (Alf P. Steinbach)
    > wrote in comp.lang.c:
    >
    > > The C++ FAQ item 29.5 (this seems to be strongly related to C), at
    > > <url: http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.5>
    > > mentions that
    > >
    > > <quote>
    > > C++ guarantees a char is exactly one byte which is at least 8 bits, short
    > > is at least 16 bits, int is at least 16 bits, and long is at least 32
    > > bits.
    > > </quote>
    > >
    > >
    > > Questions:
    > >
    > > (1) This guarantee seems to come from the C standard. Which I don't
    > > have. Does the C++ standard really guarantee this?

    >
    > [snip]
    >
    > The fact that the C++ standard decided to cite the C standard as a
    > normative reference is irrelevant here in comp.lang.c. The POSIX
    > standard is also based on the C standard, but that doesn't make POSIX
    > topical in comp.lang.c either.
    >
    > What the C++ language guarantees is 100% off-topic in c.l.c, period.
    > The fact that the C++ standard does or does not refer to any or all
    > parts of the C standard has no meaning at all in terms of C.


    You mean, you don't have the slightest clue about the C aspects (although
    you could easily check up on that, since you do have that standard), and
    therefore choose to answer the 1/3 C++ part -- with some sour grapes.

    Have a nice weekend.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Feb 6, 2005
    #15
  16. Alf P. Steinbach

    Jack Klein Guest

    On Sun, 06 Feb 2005 02:16:08 GMT, (Alf P. Steinbach)
    wrote in comp.lang.c:

    > * Jack Klein:
    > > On Sat, 05 Feb 2005 13:11:04 GMT, (Alf P. Steinbach)
    > > wrote in comp.lang.c:
    > >
    > > > The C++ FAQ item 29.5 (this seems to be strongly related to C), at
    > > > <url: http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.5>
    > > > mentions that
    > > >
    > > > <quote>
    > > > C++ guarantees a char is exactly one byte which is at least 8 bits, short
    > > > is at least 16 bits, int is at least 16 bits, and long is at least 32
    > > > bits.
    > > > </quote>
    > > >
    > > >
    > > > Questions:
    > > >
    > > > (1) This guarantee seems to come from the C standard. Which I don't
    > > > have. Does the C++ standard really guarantee this?

    > >
    > > [snip]
    > >
    > > The fact that the C++ standard decided to cite the C standard as a
    > > normative reference is irrelevant here in comp.lang.c. The POSIX
    > > standard is also based on the C standard, but that doesn't make POSIX
    > > topical in comp.lang.c either.
    > >
    > > What the C++ language guarantees is 100% off-topic in c.l.c, period.
    > > The fact that the C++ standard does or does not refer to any or all
    > > parts of the C standard has no meaning at all in terms of C.

    >
    > You mean, you don't have the slightest clue about the C aspects (although
    > you could easily check up on that, since you do have that standard), and
    > therefore choose to answer the 1/3 C++ part -- with some sour grapes.


    Yes, I do, and had you posted this to comp.lang.c++ ONLY, I would have
    been happy to answer based on what the C++ standard inherits from the
    C standard.

    But whether the C++ standard decided to incorporate the C standard in
    its entirety, which it does not, or decided to only incorporate the
    third comma on page 47, which it also does not, it not a C language
    issue or topical for comp.lang.c at all.

    There is no mention of the C++ language at all in the (now superceded
    version) of the C standard that C++ chose to incorporate.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    ..lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Feb 6, 2005
    #16
  17. On Sat, 5 Feb 2005 20:30:18 +0000 (UTC), in comp.lang.c , infobahn
    <> wrote:

    >Victor Bazarov wrote:
    >>
    >> I wonder what _exactly_ does your copy say in 3.9.1/1 that makes you
    >> derive that 'char <= short <= int'. But that doesn't matter. You are
    >> actually correct, the C standard defined those relationships between
    >> type sizes.

    >
    >C&V please.


    5.2.4.2.1 Sizes of Integral types.




    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
     
    Mark McIntyre, Feb 6, 2005
    #17
  18. On Sun, 06 Feb 2005 02:16:08 GMT, in comp.lang.c , (Alf P.
    Steinbach) wrote:

    >* Jack Klein:
    >>
    >> What the C++ language guarantees is 100% off-topic in c.l.c, period.
    >> The fact that the C++ standard does or does not refer to any or all
    >> parts of the C standard has no meaning at all in terms of C.

    >
    >You mean, you don't have the slightest clue about the C aspects


    Before posting such remarks, you might want to check up on Jack's
    credentials, posting history etc. You just made a fool of yourself.


    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
     
    Mark McIntyre, Feb 6, 2005
    #18
  19. Mark McIntyre <> writes:
    > On Sat, 5 Feb 2005 20:30:18 +0000 (UTC), in comp.lang.c , infobahn
    > <> wrote:
    >
    >>Victor Bazarov wrote:
    >>>
    >>> I wonder what _exactly_ does your copy say in 3.9.1/1 that makes you
    >>> derive that 'char <= short <= int'. But that doesn't matter. You are
    >>> actually correct, the C standard defined those relationships between
    >>> type sizes.

    >>
    >>C&V please.

    >
    > 5.2.4.2.1 Sizes of Integral types.


    Which actually discusses the ranges of integer types, which, in the
    presence of padding bits, may not be directly related to their sizes.
    A sufficiently perverse implementation could have
    sizeof(long) < sizeof(int).

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Feb 6, 2005
    #19
  20. * Mark McIntyre:
    > On Sun, 06 Feb 2005 02:16:08 GMT, in comp.lang.c , (Alf P.
    > Steinbach) wrote:
    >
    > >* Jack Klein:
    > >>
    > >> What the C++ language guarantees is 100% off-topic in c.l.c, period.
    > >> The fact that the C++ standard does or does not refer to any or all
    > >> parts of the C standard has no meaning at all in terms of C.

    > >
    > >You mean, you don't have the slightest clue about the C aspects

    >
    > Before posting such remarks, you might want to check up on Jack's
    > credentials, posting history etc.


    I know Jack's posting history for several years.


    > You just made a fool of yourself.


    Before posting such remarks, you might want to check up on my
    credentials, posting history etc.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Feb 6, 2005
    #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. Alf P. Steinbach
    Replies:
    30
    Views:
    891
    Dave Thompson
    Feb 14, 2005
  2. Kyle Kolander
    Replies:
    3
    Views:
    302
    John Carson
    Jul 14, 2005
  3. Kyle Kolander

    fundamental types

    Kyle Kolander, Jul 14, 2005, in forum: C++
    Replies:
    8
    Views:
    368
    Kyle Kolander
    Jul 15, 2005
  4. Francesco S. Carta
    Replies:
    8
    Views:
    322
    Francesco S. Carta
    Aug 29, 2010
  5. Pavel
    Replies:
    13
    Views:
    1,116
    Pavel
    Jul 5, 2011
Loading...

Share This Page