473,320 Members | 1,922 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

FAQ issue: Guaranteed value ranges of fundamental types?

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?
Nov 14 '05 #1
30 1365
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
Nov 14 '05 #2
"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
Nov 14 '05 #3
* 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?
Nov 14 '05 #4
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
Nov 14 '05 #5
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.

Nov 14 '05 #6
"Andreas Huber" <ah********************@yahoo.com> 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
Nov 14 '05 #7
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.
Nov 14 '05 #8
"infobahn" <in******@btinternet.com> 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
Nov 14 '05 #9
"Andreas Huber" <ah********************@yahoo.com> 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) ks***@mib.org <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.
Nov 14 '05 #10
Victor Bazarov wrote:
"Andreas Huber" <ah********************@yahoo.com> 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.

Nov 14 '05 #11
"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
Nov 14 '05 #12
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
Nov 14 '05 #13
On Sat, 05 Feb 2005 13:11:04 GMT, al***@start.no (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/~a...FAQ-acllc.html
Nov 14 '05 #14
* Jack Klein:
On Sat, 05 Feb 2005 13:11:04 GMT, al***@start.no (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?
Nov 14 '05 #15
On Sun, 06 Feb 2005 02:16:08 GMT, al***@start.no (Alf P. Steinbach)
wrote in comp.lang.c:
* Jack Klein:
On Sat, 05 Feb 2005 13:11:04 GMT, al***@start.no (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/~a...FAQ-acllc.html
Nov 14 '05 #16
On Sat, 5 Feb 2005 20:30:18 +0000 (UTC), in comp.lang.c , infobahn
<in******@btinternet.com> 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>
Nov 14 '05 #17
On Sun, 06 Feb 2005 02:16:08 GMT, in comp.lang.c , al***@start.no (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>
Nov 14 '05 #18
Mark McIntyre <ma**********@spamcop.net> writes:
On Sat, 5 Feb 2005 20:30:18 +0000 (UTC), in comp.lang.c , infobahn
<in******@btinternet.com> 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) ks***@mib.org <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.
Nov 14 '05 #19
* Mark McIntyre:
On Sun, 06 Feb 2005 02:16:08 GMT, in comp.lang.c , al***@start.no (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?
Nov 14 '05 #20
* Jack Klein:
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.


That is literally true but irrelevant.

The main concerns only the C standard. You think the C standard is off-topic
in [clc]? That something else is also mentioned is irrelevant for topicality.

See <url: http://www.nizkor.org/features/fallacies/red-herring.html> and
<url: http://www.nizkor.org/features/fallacies/straw-man.html> (good
idea to study the other fallacies, too :-)

--
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?
Nov 14 '05 #21
Mark McIntyre wrote:

On Sat, 5 Feb 2005 20:30:18 +0000 (UTC), in comp.lang.c , infobahn
<in******@btinternet.com> 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.


That section talks about value ranges. Victor Barazov claimed that the
Standard defined those relationships between type *sizes*. That is, he
seemed to mean, for example, that sizeof(short) is guaranteed to be <=
sizeof(int). I can see nothing in 5.2.4.2.1 that requires this. Please
be more explicit. Thank you.
Nov 14 '05 #22
On Sun, 06 Feb 2005 14:19:58 GMT, in comp.lang.c , al***@start.no (Alf P.
Steinbach) wrote:
Before posting such remarks, you might want to check up on my
credentials, posting history etc.


I could do, but I wasn't the one making a fool of myself.

--
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 =----
Nov 14 '05 #23
On Sun, 6 Feb 2005 16:10:19 +0000 (UTC), in comp.lang.c , infobahn
<in******@btinternet.com> wrote:
Mark McIntyre wrote:

5.2.4.2.1 Sizes of Integral types.
That section talks about value ranges.


Yes
Victor Barazov claimed that the
Standard defined those relationships between type *sizes*.
Yes.
That is, he
seemed to mean, for example, that sizeof(short) is guaranteed to be <=
sizeof(int). I can see nothing in 5.2.4.2.1 that requires this. Please
be more explicit. Thank you.


*shrug*. Only a pedant would argue about the difference. I know, CLC is
full of 'em. SIL.
--
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 =----
Nov 14 '05 #24
* Mark McIntyre:
* Alf P. Steinbach:


[reinserted]
* Mark McIntyre:
Before posting such remarks, you might want to check up on Jack's
credentials, posting history etc.
[/reinserted]
Before posting such remarks, you might want to check up on my
credentials, posting history etc.


I could do, but I wasn't the one making a fool of myself.


Don't engage in ad hominem attacks, don't misquote other people or quote them
out of context, follow your own advice, and you may become a happy person. :-)

--
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?
Nov 14 '05 #25
Mark McIntyre wrote:

On Sun, 6 Feb 2005 16:10:19 +0000 (UTC), in comp.lang.c , infobahn
<in******@btinternet.com> wrote:
That is, he
seemed to mean, for example, that sizeof(short) is guaranteed to be <=
sizeof(int). I can see nothing in 5.2.4.2.1 that requires this. Please
be more explicit. Thank you.


*shrug*. Only a pedant would argue about the difference. I know, CLC is
full of 'em. SIL.


There's right, and there's wrong, and there's a grey area. The
original claim was slap bang in the middle of the "wrong", and
there's nothing "pedantic" about saying so. But, even if there
is, I'd rather be pedantic than wrong.
Nov 14 '05 #26
Mark McIntyre wrote:
*shrug*. Only a pedant would argue about the difference. I know, CLC is
full of 'em. SIL.


What is "SIL"?
Nov 14 '05 #27
Julie wrote:
Mark McIntyre wrote:
*shrug*. Only a pedant would argue about the difference. I know, CLC is
full of 'em. SIL.


What is "SIL"?


Presumably, "such is life".
Cheers
Michael
--
E-Mail: Mine is a gmx dot de address.

Nov 14 '05 #28
On Tue, 08 Feb 2005 08:22:25 -0800, in comp.lang.c , Julie
<ju***@nospam.com> wrote:
Mark McIntyre wrote:
*shrug*. Only a pedant would argue about the difference. I know, CLC is
full of 'em. SIL.


What is "SIL"?


Such Is Life.

--
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 =----
Nov 14 '05 #29
On Tue, 08 Feb 2005 00:01:15 GMT, in comp.lang.c , al***@start.no (Alf P.
Steinbach) wrote:
Don't engage in ad hominem attacks, don't misquote other people or quote them
out of context,
I did none of these things, but you did. Physician, heal thyself.
follow your own advice, and you may become a happy person. :-)


I'm already happy thanks.

--
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 =----
Nov 14 '05 #30
On Tue, 08 Feb 2005 19:48:13 +0000, Mark McIntyre
<ma**********@spamcop.net> wrote:
On Tue, 08 Feb 2005 08:22:25 -0800, in comp.lang.c , Julie
<ju***@nospam.com> wrote:
Mark McIntyre wrote:
*shrug*. Only a pedant would argue about the difference. I know, CLC is
full of 'em. SIL.


What is "SIL"?


Such Is Life.


Perhaps ironically it is also System Implementation Language, the term
that was common around the time C was created for the category in
which it falls along with other languages that have more or less
fallen by the wayside like BLISS, PL/M, and the MODULAs.

- David.Thompson1 at worldnet.att.net
Nov 14 '05 #31

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

15
by: Ladvánszky Károly | last post by:
Entering 3.4 in Python yields 3.3999999999999999. I know it is due to the fact that 3.4 can not be precisely expressed by the powers of 2. Can the float handling rules of the underlying layers be...
30
by: Alf P. Steinbach | last post by:
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...
8
by: Kyle Kolander | last post by:
Sorry, I sent this to comp.std.c++ and meant to send it here as well... Why are the minimum size guarantees for fundamental types intentionally omitted from section 3.9.1 Fundamental types of...
2
by: Ben O'Steen | last post by:
Scenario: ========= Using PyGame in particular, I am trying to write an application that will run a scripted timeline of events, eg at 5.5 seconds, play xxx.mp3 and put the image of a ball on...
18
by: ranjeet.gupta | last post by:
Dear ALL As we know that when we declare the union then we have the size of the union which is the size of the highest data type as in the below case the size should be 4 (For my case and...
22
by: subramanian100in | last post by:
Consider the following program #include <limits.h> #include <stddef.h> int main(void) { size_t size; size_t bytes = sizeof(size_t);
14
by: n3o | last post by:
Hello Comp.Lang.C Members, I have an issue with user input that I have been trying to figure out for the longest. For instance, let's say you have something like this: void foo() { int num;...
1
by: jehugaleahsa | last post by:
Hello: I am experiencing performance related issues when my custom data structures work with value types. I use generics to prevent boxing wherever I can. For instance, I use IEqualityComparer,...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.