Portable int?

[Phui Hock]

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.

 

[Tom St Denis]

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

 

[Eric Sosman]

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?

 

[Tom St Denis]

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

 

[Joona I Palaste]

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.

 

[Tom St Denis]

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

 

[Arthur J. O'Dwyer]

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

 

[Tom St Denis]

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

 

[Alan Balmer]

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.

 

[E. Robert Tisdale]

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.

 

[Carsten Hansen]

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

The 68000 is a hybrid 16-bit/32-bit processor. The title of Motorola's
manual is "M68000 16/32-bit microprocessor".
Registers are 32-bits. But the ALU is only 16-bits. Calculation on 32-bit
numbers is done in two operations using micro code. Most 32-bit instructions
takes twice the time of the corresponding 16-bit instruction.
Some C compilers use 16-bit int. Others 32-bits. Others again make the
length of int a user option.

Carsten Hansen

 

[Alex]

tombox root # gcc -O2 -Wall -W --std=c99 -pedantic -c test.c

^^^^^^

<OT> Shame on you! </OT>

Alex

 

[Richard Bos]

^^^^^^

<OT> Shame on you! </OT>

He'll learn. Sooner or later, they all do. Of course, it'll cost him
half a dozen years' worth of files, but hey, who cares about porn JPEGs
and C source which voids main()?

Richard

 

[Dan Pop]

^^^^^^

<OT> Shame on you! </OT>

It's typical for clueless people who are unable to understand the big
advantages of having limited access rights on the system.

Dan

 

[Tom St Denis]

^^^^^^

<OT> Shame on you! </OT>

I run gentoo and the only server I have [apache] runs as user/group
apache....

What is your point again?

Oh yeah, stupid ass lame script kiddie comment about how l33t you are.

Tom

 

[Tom St Denis]

He'll learn. Sooner or later, they all do. Of course, it'll cost him
half a dozen years' worth of files, but hey, who cares about porn JPEGs
and C source which voids main()?

How so?

Go ahead and break into apache. You will get my website [provided you can
do it]. That's the only server I'm running. I build all my programs from
scratch. I do weekly backups, um... whatelse...

oh yeah, you're an ass who doesn't know jack f'ing squat.

Tom

 

[Alan Balmer]

He'll learn. Sooner or later, they all do. Of course, it'll cost him
half a dozen years' worth of files, but hey, who cares about porn JPEGs
and C source which voids main()?

How so?

Go ahead and break into apache. You will get my website [provided you can
do it]. That's the only server I'm running. I build all my programs from
scratch. I do weekly backups, um... whatelse...

I thought Richard was predicting that sooner or later, you're going to
do it to yourself, no Apache cracking needed. I'm not brave enough to
do development from root.

 

[Joona I Palaste]

It's typical for clueless people who are unable to understand the big
advantages of having limited access rights on the system.

I don't know very much about Unix. I mean, I'm by far the most Unix-
knowledgeable person in my family (next comes my 13-year-old brother,
whose Unix experience is limited to trying Linux out once), but I
still don't know very much. Therefore I always run as non-root unless
I have a special reason to run as root.

 

[BruceS]

I don't know very much about Unix. I mean, I'm by far the most Unix-
knowledgeable person in my family (next comes my 13-year-old brother,
whose Unix experience is limited to trying Linux out once), but I
still don't know very much. Therefore I always run as non-root unless
I have a special reason to run as root.

Oddly enough, that sounds very much like the behavior of those who *do* know
a lot about Unix.

I don't know a lot about lawnmowers, so I never use mine underwater or
overhead.

 

[Joona I Palaste]

Oddly enough, that sounds very much like the behavior of those who *do* know
a lot about Unix.

I know enough to know that I don't know everything. I am well aware of
the things I could accidentally do if I ran as root. If I knew more, I
wouldn't do those things even if I ran as root...

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"I said 'play as you've never played before', not 'play as IF you've never
played before'!"
- Andy Capp