«

I'm just curious, why don't we just use uint8_t or uint16_t for example
to declare an integer type storage when we know int is always
platform-dependent? I do not have programming experience on other
platform except M$ Windows and Linux.

Thank you.

"Phui Hock" <> wrote in message
news: om...
> I'm just curious, why don't we just use uint8_t or uint16_t for example
> to declare an integer type storage when we know int is always
> platform-dependent? I do not have programming experience on other
> platform except M$ Windows and Linux.

Cuz that's stupid. The reason "int" isn't always a fixed size [it does have
minimums btw] is that it's meant to be an ideal platform size. E.g. for the
8086 it's 16-bits while for the 68000 it's 32-bits.

The idea is if I want something simple like

int x;
for (x = 0; x < strlen(buf); x++) {
buf[x] = tolower(buf[x]);
}

[or whatever].... the variable "x" should be easily manageable [e.g. not
32-bits on an 8086 and not 16-bits on a 68k].

A "long" was always meant to be "slightly less convenient but larger range".
That's not always the case though. on 68k/386 compilers "long" is typically
synonymous for "int" [except when array expressions are present cuz we all
know they must be int].

Tom

Tom St Denis wrote:
>
> "Phui Hock" <> wrote in message
> news: om...
> > I'm just curious, why don't we just use uint8_t or uint16_t for example
> > to declare an integer type storage when we know int is always
> > platform-dependent? I do not have programming experience on other
> > platform except M$ Windows and Linux.
>
> Cuz that's stupid. The reason "int" isn't always a fixed size [it does have
> minimums btw] is that it's meant to be an ideal platform size. E.g. for the
> 8086 it's 16-bits while for the 68000 it's 32-bits.
>
> The idea is if I want something simple like
>
> int x;
> for (x = 0; x < strlen(buf); x++) {
> buf[x] = tolower(buf[x]);
> }
>
> [or whatever].... the variable "x" should be easily manageable [e.g. not
> 32-bits on an 8086 and not 16-bits on a 68k].
>
> A "long" was always meant to be "slightly less convenient but larger range".
> That's not always the case though. on 68k/386 compilers "long" is typically
> synonymous for "int" [except when array expressions are present cuz we all
> know they must be int].

I was nodding my head and agreeing with you right up
until that final [remark]. Would you mind explaining just
what it is "we all know," because I can't figure it out.
What's an "array expression," and what has it to do with
the int-ness of anything?

--

"Eric Sosman" <> wrote in message
news:...
> I was nodding my head and agreeing with you right up
> until that final [remark]. Would you mind explaining just
> what it is "we all know," because I can't figure it out.
> What's an "array expression," and what has it to do with
> the int-ness of anything?

When an expression is used to index an array...e.g.

int *p;

p[(some expression)] = (some other expression);

The expression on the left has to [technically] evaluate to an integer "int"
data type. I'm fairly certain it's a rule but I couldn't quote you the
section/page num of it.

Tom

Tom St Denis <> scribbled the following:
> "Eric Sosman" <> wrote in message
> news:...
>> I was nodding my head and agreeing with you right up
>> until that final [remark]. Would you mind explaining just
>> what it is "we all know," because I can't figure it out.
>> What's an "array expression," and what has it to do with
>> the int-ness of anything?

> When an expression is used to index an array...e.g.

> int *p;

> p[(some expression)] = (some other expression);

> The expression on the left has to [technically] evaluate to an integer "int"
> data type. I'm fairly certain it's a rule but I couldn't quote you the
> section/page num of it.

AFAIK you're wrong. It doesn't have to evaluate to int. It merely has to
evaluate to some type that is assignable to int. For example, p[0l]
should be valid, as should be p[*"Hello world!"]. What about p[0.0]?
But, AYCS, that's only AFAIK, and it might be that WIKIW. YHBW. HTH,
HAND.

--
/-- Joona Palaste () ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"This is a personnel commuter."
- Train driver in Scientific American

"Joona I Palaste" <> wrote in message
news:borm65$lnc$...
> AFAIK you're wrong. It doesn't have to evaluate to int. It merely has to
> evaluate to some type that is assignable to int. For example, p[0l]
> should be valid, as should be p[*"Hello world!"]. What about p[0.0]?
> But, AYCS, that's only AFAIK, and it might be that WIKIW. YHBW. HTH,
> HAND.

Seems you're right. Given

int main(void)
{
char buf[10];

buf[0l] = 'a';
buf[0ul] = 'a';
buf[*"hello"] = 'a';
buf[0.0] = 'a';
return 0;
}

tombox root # gcc -O2 -Wall -W --std=c99 -pedantic -c test.c
test.c: In function `main':
test.c:7: warning: array subscript has type `char'
test.c:8: array subscript is not an integer

Tom

On Tue, 11 Nov 2003, Tom St Denis wrote:
>
> p[(some expression)] = (some other expression);
>
> [Tom thought...] The expression on the left has to [technically]
> evaluate to an integer "int" data type. I'm fairly certain it's a rule
> but I couldn't quote you the section/page num of it.

Close, but no cigar. The array-indexing [] operator takes
one pointer to a (complete) object type and one integer type.
From N869 s6.5.2.1 (Array subscripting):

[#1] One of the expressions [i.e., 'p' or '(some expression)', above]
shall have type ``pointer to object type'', the other expression
shall have integer type, and the result has type ``type''.

The integer types are described in section 6.2.5, particularly #17.

HTH,
-Arthur

"Arthur J. O'Dwyer" <> wrote in message
newsine.LNX.4.58-...
>
> On Tue, 11 Nov 2003, Tom St Denis wrote:
> >
> > p[(some expression)] = (some other expression);
> >
> > [Tom thought...] The expression on the left has to [technically]
> > evaluate to an integer "int" data type. I'm fairly certain it's a rule
> > but I couldn't quote you the section/page num of it.
>
> Close, but no cigar. The array-indexing [] operator takes
> one pointer to a (complete) object type and one integer type.
> From N869 s6.5.2.1 (Array subscripting):
>
> [#1] One of the expressions [i.e., 'p' or '(some expression)', above]
> shall have type ``pointer to object type'', the other expression
> shall have integer type, and the result has type ``type''.
>
> The integer types are described in section 6.2.5, particularly #17.

Swing and a miss. What probably happend is that someone else asked this, I
read the reply and munged "integer type" with "int".

Tom

On 11 Nov 2003 12:42:13 -0800, (Phui Hock) wrote:

>I'm just curious, why don't we just use uint8_t or uint16_t for example
>to declare an integer type storage when we know int is always
>platform-dependent? I do not have programming experience on other
>platform except M$ Windows and Linux.
>
>Thank you.

When the size of an integer variable is critical, we do. Otherwise,
the implementation probably has good reasons for the default size.

You do need to remember that support for the uint-type integers is not
universal.

--
Al Balmer
Balmer Consulting

Phui Hock wrote:

> Why don't we just use uint8_t or uint16_t for example
> to declare an integer type storage
> when we know int is always platform-dependent?
> I do not have programming experience
> on other platform except M$ Windows and Linux.

Because there is no guarantee that uint8_t or uint16_t
will actually be supported by every C [99] compiler.
Use them only if you are certain that they are supported
on every potential target platform for your software.

To my knowledge, they are supported
by every C99 compiler for Windows on Intel computers
and Linux on Intel computers and IBM/Motorola PowerPC.