Standard integer types vs <stdint.h> types

[euler70]

char and unsigned char have specific purposes: char is useful for
representing characters of the basic execution character set and
unsigned char is useful for representing the values of individual
bytes. The remainder of the standard integer types are general
purpose. Their only requirement is to satisfy a minimum range of
values, and also int "has the natural size suggested by the
architecture of the execution environment". What are the reasons for
using these types instead of the [u]int_fastN_t types of <stdint.h>?

If I want just a signed integer with at least 16 width, then why
choose int instead of int_fast16_t? int_fast16_t is the "fastest"
signed integer type that has at least 16 width, while int is simply a
signed integer type that has at least 16 width. It seems that choosing
int_fast16_t is at least as good as choosing int. This argument can be
made for N=8,16,32,64, and for the corresponding unsigned types.
<stdint.halso offers [u]int_leastN_t types, which are useful when
keeping a small storage size is the greatest concern.

The only benefit of using the standard integer types I can see is that
their ranges may expand as the C standard progresses, so code that
uses them might stay useful over time. For example fseek of <stdio.h>
uses a long for its offset parameter, so if the range of long grows
then fseek will automatically offer a wider range of offsets.

It's also interesting to note (or maybe not) that in the Windows
world, the idea of long being general purpose has somewhat been
destroyed and long has become a type that must have exactly 32 bits.

[James Kuyper]

CBFalconer wrote:
....

Well, if the compiling end uses a C99 compiler, you can't replace
<stdint.h[1], and thus have to use "stdint.h". Now you are
forbidden to redefine anything defined in <stdint.h>. So, if you
can adhere to all those requirements (and possibly others) and
produce a fully portable "stdint.h", go to it. Show us the result,
please.

You can create a file named stdint.h, arrange for it to be used when an
implementation doesn't provide it's own stdint.h, and make sure it
doesn't get used when the implementation does provide one. How can you
"arrange" these things? There's no portable answer. It doesn't say any
more about this issue than it does about what you have to do to make use
of a third-party library. Nonetheless, it's perfectly feasible on every
platform I've tried. At the very least, deleting the file should be
sufficient on most platforms to remove any possibility of it interfering
with use of the implementation-defined version.

[dj3vande]

In article <XL******************@text.news.blueyonder.co.uk >,
Bart C <[e-mail]:

><dj******@csclub.uwaterloo.ca.invalidwrote in message
news:fm**********@rumours.uwaterloo.ca...

>In article <6c******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>>Flash Gordon said:

>>>Personally I don't find underscores in names
a problem for scanning, especially once I have learnt the patterns.

Is ugliness a problem? I guess ugliness is in the eye of the beholder.

For exact-width types, I actually lean toward considering ugliness a
Good Thing.

Most people who think they need exact-width types are wrong, and making
them as ugly and inconvenient as possible discourages their use (which
on the whole is a Good Thing);...

If you mix languages like C and something else, it sort of becomes important
to know what bit-widths C is using.

Every FFI[1] I've ever used (both of them) defines the types it uses at
the interface as "a C int" (or other C type), which makes this problem
go away.

>It becomes worse when mixing two implementations of C which cannot agree
what they mean by int or long int, on the same hardware.

If they're both following a consistent ABI that's defined for the
platform they're running on, they shouldn't be disagreeing on the sizes
of their types.
(One possible exception is when you have a single platform with, say, a
32-bit ABI and a 64-bit ABI that can coexist, but the compiler will
still need to know which one it's talking to, and once it knows that it
has enough information to do The Right Thing without further programmer
input.)
If you don't have a consistent ABI, you have bigger problems than
disagreeing on the sizes of your types.

>Maybe CPU manufacturers like Intel should keep the word sizes of their
processors secret to encourage good portable programming.

No need. Competent programmers who are writing portable code already
know to ignore, and everybody else will find some way to find it out.
dave

[1] Foreign Function Interface, which in practice usually ends up being
"How to call entry points that are, or at least look like, C
functions, and (if you're lucky) how to make such entry points that
you can be called by"

--
Dave Vandervies dj3vande at eskimo dot com
And if you're writing code for graphical *and* ungraphical toasters,
what's wrong with something like this?
--Richard Heathfield in comp.lang

[dj3vande]

In article <47***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:

>Well, if the compiling end uses a C99 compiler, you can't replace
<stdint.h[1], and thus have to use "stdint.h". Now you are
forbidden to redefine anything defined in <stdint.h>. So, if you
can adhere to all those requirements (and possibly others) and
produce a fully portable "stdint.h", go to it. Show us the result,
please.

--------"stdint.h"
#if __STDC_VERSION__ >= 199901L
#include <stdint.h>
#else
#include "my-stdint.h"
#endif
--------

If you're really paranoid, you can include this in my-stdint.h:
--------
#if __STDC_VERSION__ >= 199901L
#error "my-stdint.h should not be #included in C99 code; use <stdint.h>"
#endif
--------
dave

--
Dave Vandervies dj3vande at eskimo dot com
And if you're writing code for graphical *and* ungraphical toasters,
what's wrong with something like this?
--Richard Heathfield in comp.lang

[CJ]

On 19 Jan 2008 at 23:26, jacob navia wrote:

Richard Harter wrote:

>Er, he didn't say that ints are floats, ergo your demonstration
doesn't falsify what he did say. He said, and I quote "Floating
point is a superset of integers". You responded with, "If that
is true, then all integers are floating point numbers." His
statement, and your statement refer to numbers, which is a
mathematical concept, and not to C number types. It will not do
to say that you were talking about number types - if you mean to
be pedantic then you need to carry it through.

In maths N is a subset of R, by the way.

Not according to any standard definitions of N and R, though for sure
there is a canonical injection from N to R.

[Richard Bos]

jacob navia <ja***@nospam.comwrote:

Flash Gordon wrote:

There *are* times when you need to know, and there are times when you
need to know a type has at least a specific range, but a lot of the time
you do not care if it is larger.

Rarely.

If I write

int a = 45000;

that will not work in 16 bit implementations.

You HAVE to know the bitsize to know how much data
you can put into an integer!

No, you don't. In fact, bit size can be misleading. Maybe it's a perfect
idea on all the systems you have experience with, but that is no excuse
for not being clearer _and_ more secure at the same time.

Use INT_MAX. It exists for a reason.

Richard

[Bart C]

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:47*****************@news.xs4all.nl...

jacob navia <ja***@nospam.comwrote:

>int a = 45000;

that will not work in 16 bit implementations.

You HAVE to know the bitsize to know how much data
you can put into an integer!

No, you don't. In fact, bit size can be misleading. Maybe it's a perfect
idea on all the systems you have experience with, but that is no excuse
for not being clearer _and_ more secure at the same time.

Use INT_MAX. It exists for a reason.

How would that be used exactly? Something like this (if it's even
possible)?:

#define INT_BIG_ENOUGH_TO_STORE(x).... /* clever macro using INT_MAX*/

Then using it as:

INT_BIG_ENOUGH_TO_STORE(45000) a=45000;

Or are you suggesting just looking at the limits and choosing the correct
int based on that? That would only work for this implementation.
--
Bart

[jacob navia]

Bart C wrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:47*****************@news.xs4all.nl...

>jacob navia <ja***@nospam.comwrote:

>>int a = 45000;

that will not work in 16 bit implementations.

You HAVE to know the bitsize to know how much data
you can put into an integer!

No, you don't. In fact, bit size can be misleading. Maybe it's a perfect
idea on all the systems you have experience with, but that is no excuse
for not being clearer _and_ more secure at the same time.

Use INT_MAX. It exists for a reason.

How would that be used exactly? Something like this (if it's even
possible)?:

#define INT_BIG_ENOUGH_TO_STORE(x).... /* clever macro using INT_MAX*/

Then using it as:

INT_BIG_ENOUGH_TO_STORE(45000) a=45000;

Or are you suggesting just looking at the limits and choosing the correct
int based on that? That would only work for this implementation.
--
Bart

I mean if I have some data (like 45 000) how the hell I am supposed to
know if the implementation supports that unless I use can hold that?

Better use the C99 solution and be safe. That was my idea.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Malcolm McLean]

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message

Malcolm McLean wrote, On 20/01/08 19:40:

>>
Most C programs use arrays very heavily. In fact it is the only basic
data structure that has direct language support.

Last time I looked C had structures.

A struct is not a basic data structure. It sounds rather silly, but it's
not.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Richard Harter]

On Mon, 21 Jan 2008 22:13:18 -0000, "Malcolm McLean"
<re*******@btinternet.comwrote:

>
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message

>Malcolm McLean wrote, On 20/01/08 19:40:

>>>
Most C programs use arrays very heavily. In fact it is the only basic
data structure that has direct language support.

Last time I looked C had structures.

A struct is not a basic data structure. It sounds rather silly, but it's
not.

I gather that computer science has been substantially revised in
the recent past.

[jacob navia]

Richard Harter wrote:

On Mon, 21 Jan 2008 22:13:18 -0000, "Malcolm McLean"
<re*******@btinternet.comwrote:

>"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message

>>Malcolm McLean wrote, On 20/01/08 19:40:
Most C programs use arrays very heavily. In fact it is the only basic
data structure that has direct language support.
Last time I looked C had structures.

A struct is not a basic data structure. It sounds rather silly, but it's
not.

I gather that computer science has been substantially revised in
the recent past.

I find this completely ridiculous. When "structs" aren't
data structures what are they then?

UFOs?

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[James Kuyper]

Harald van Dijk wrote:

On Sun, 20 Jan 2008 12:04:47 -0500, CBFalconer wrote:

>Ian Collins wrote:

>>CBFalconer wrote:
Yes, but you can do that in your own stdint.h where the platform does
not provide one (which is what I do).

Well, if the compiling end uses a C99 compiler, you can't replace
<stdint.h[1], and thus have to use "stdint.h".

No, if the compiling end uses a C99 implementation, the custom stdint.h
would simply end up unused,

There's no such guarantee. 7.1.2p3 says "If a file with the same name as
one of the above < and delimited sequences, not provided as part of
the implementation, is placed in any of the standard places that are
searched for included source files, the behavior is undefined."

Therefore, it is essential if compiling with a conforming implmentation
of C to make sure that no user-provided file named stdint.h is in any of
the standard places searched for included source files. You can't just
count on it being skipped over (unless you know that this is, in fact,
the form that undefined behavior takes for a particular implementation).

[James Kuyper]

jacob navia wrote:

Richard Harter wrote:

>On Mon, 21 Jan 2008 22:13:18 -0000, "Malcolm McLean"
<re*******@btinternet.comwrote:

....

>>A struct is not a basic data structure. It sounds rather silly, but
it's not.

I gather that computer science has been substantially revised in
the recent past.

I find this completely ridiculous. When "structs" aren't
data structures what are they then?

UFOs?

He's not denying that they aren't data structures, he's denying that
they are basic. The C standard doesn't define such a concept as "basic
data types", but it does say that struct types are derived types.

[James Kuyper]

Bart C wrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:47*****************@news.xs4all.nl...

>jacob navia <ja***@nospam.comwrote:

>>int a = 45000;

that will not work in 16 bit implementations.

You HAVE to know the bitsize to know how much data
you can put into an integer!

No, you don't. In fact, bit size can be misleading. Maybe it's a perfect
idea on all the systems you have experience with, but that is no excuse
for not being clearer _and_ more secure at the same time.

Use INT_MAX. It exists for a reason.

How would that be used exactly? Something like this (if it's even
possible)?:

#define INT_BIG_ENOUGH_TO_STORE(x).... /* clever macro using INT_MAX*/

No, you use conditional compilation of typedefs, of course.

....

Or are you suggesting just looking at the limits and choosing the correct
int based on that? That would only work for this implementation.

Properly written, conditionally compiled typedefs should be quite
adequately portable, though less efficient in C99 than using the
<stdint.htypedefs.

[Keith Thompson]

James Kuyper <ja*********@verizon.netwrites:

jacob navia wrote:

>Richard Harter wrote:

>>On Mon, 21 Jan 2008 22:13:18 -0000, "Malcolm McLean"
<re*******@btinternet.comwrote:

...

>>>A struct is not a basic data structure. It sounds rather silly,
but it's not.

I gather that computer science has been substantially revised in
the recent past.

I find this completely ridiculous. When "structs" aren't
data structures what are they then?

UFOs?

He's not denying that they aren't data structures, he's denying that
they are basic. The C standard doesn't define such a concept as "basic
data types", but it does say that struct types are derived types.

It also says that array types are derived types. The kinds of derived
types are arrays, structures, unions, functions, and pointers; see C99
6.2.5.

Since Malcolm acknowledges that his claim "sounds rather silly",
perhaps he'd care to justify it.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Bart C]

"James Kuyper" <ja*********@verizon.netwrote in message
news:D6flj.3495$hk4.3034@trnddc03...

Bart C wrote:

>"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:47*****************@news.xs4all.nl...

>>jacob navia <ja***@nospam.comwrote:

>>>int a = 45000;

>>Use INT_MAX. It exists for a reason.

How would that be used exactly? Something like this (if it's even
possible)?:

#define INT_BIG_ENOUGH_TO_STORE(x).... /* clever macro using INT_MAX*/

No, you use conditional compilation of typedefs, of course.

Ok, like this then?

#include <limits.h>
#if INT_MAX>=2147483647
typedef int myint32;
#elif LONG_MAX>=2147483647
typedef long int myint32;
#else
typedef long long int myint32;
#endif

myint32 a=2000000000;

(Although I can see a few pitfalls like having a possible varying suffix to
int constants, and varying printf format specifier, depending on which int
is chosen.)

--
Bart

[Malcolm McLean]

"Bart C" <[e-mail] in message

Which (non-esoteric) languages have these built-in /to the language/ >
rather than in the library?

Lisp is structured around linked lists.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[James Kuyper]

Bart C wrote:

"James Kuyper" <ja*********@verizon.netwrote in message
news:D6flj.3495$hk4.3034@trnddc03...

>Bart C wrote:

....

>>How would that be used exactly? Something like this (if it's even
possible)?:

#define INT_BIG_ENOUGH_TO_STORE(x).... /* clever macro using INT_MAX*/

No, you use conditional compilation of typedefs, of course.

Ok, like this then?

#include <limits.h>
#if INT_MAX>=2147483647
typedef int myint32;
#elif LONG_MAX>=2147483647
typedef long int myint32;
#else
typedef long long int myint32;
#endif

myint32 a=2000000000;

Yes, that's the idea.

(Although I can see a few pitfalls like having a possible varying suffix to
int constants, and varying printf format specifier, depending on which int
is chosen.)

You can also conditionally compile code which #defines macros for
attaching the appropriate suffix, if necessary, and for the appropriate
printf format specifier, exactly as is done in typical implementations
of <stdint.h>. That is precisely what the publicly available
C90-compatible portable versions of stdint.h do. That's why using
<stdint.his a better way to do this, even if you have to use one of
the C90 versions when compiling in C90 (and make sure it is NOT used
when compiling in C99).

[Jean-Marc Bourguet]

"Malcolm McLean" <re*******@btinternet.comwrites:

"Bart C" <[e-mail] in message

Which (non-esoteric) languages have these built-in /to the language/ >
rather than in the library?

Lisp is structured around linked lists.

Lisp is structured around binary trees and consider linked lists as a
special case of binary trees.

Yours,

--
Jean-Marc

[CBFalconer]

jacob navia wrote:

Richard Harter wrote:

>"Malcolm McLean" <re*******@btinternet.comwrote:

.... snip ...

>>

>>A struct is not a basic data structure. It sounds rather silly,
but it's not.

I gather that computer science has been substantially revised in
the recent past.

I find this completely ridiculous. When "structs" aren't data
structures what are they then?

Notice the word 'basic'. structs could be called compound objects.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[Ben Bacarisse]

CBFalconer <cb********@yahoo.comwrites:

jacob navia wrote:

>Richard Harter wrote:

>>"Malcolm McLean" <re*******@btinternet.comwrote:

... snip ...

>>>
A struct is not a basic data structure. It sounds rather silly,
but it's not.

I gather that computer science has been substantially revised in
the recent past.

I find this completely ridiculous. When "structs" aren't data
structures what are they then?

Notice the word 'basic'. structs could be called compound objects.

Malcolm had stated that arrays are the only "basic data structures"
(with support in the language). They too could be called compound.

--
Ben.

[Malcolm McLean]

"Ben Bacarisse" <be********@bsb.me.ukwrote in message

Malcolm had stated that arrays are the only "basic data structures"
(with support in the language). They too could be called compound.

In chemistry we'd call structs "compounds" and arrays "polymers".

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Army1987]

Malcolm McLean wrote:

That's a totally untypical program. Most C programs use arrays very heavily.
In fact it is the only basic data structure that has direct language
support.
Sometimes in older C programs you see pointer notation used where array
dereferencing would be clearer, I'll grant you. That's technically an
exception to my point, even though an integer will be used to count down the
travelling pointer.

I can't see any reason why a program using:
for (p = a; p < a + n; p++) {
frobnicate(*a);
}
is any more "untypical" or less "clear" than
for (i = 0; i < n; i++) {
frobnicate(a[i]);
}

--
Army1987 (Replace "NOSPAM" with "email")

[Malcolm McLean]

"Army1987" <ar******@NOSPAM.itwrote in message

Malcolm McLean wrote:

>That's a totally untypical program. Most C programs use arrays very
heavily.
In fact it is the only basic data structure that has direct language
support.
Sometimes in older C programs you see pointer notation used where array
dereferencing would be clearer, I'll grant you. That's technically an
exception to my point, even though an integer will be used to count down
the
travelling pointer.

I can't see any reason why a program using:
for (p = a; p < a + n; p++) {
frobnicate(*a);
}
is any more "untypical" or less "clear" than
for (i = 0; i < n; i++) {
frobnicate(a[i]);
}

You've answered your own question.
Example 1 is incorrect.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Richard Tobin]

In article <1d******************************@bt.com>,
Malcolm McLean <re*******@btinternet.comwrote:

>I can't see any reason why a program using:
for (p = a; p < a + n; p++) {
frobnicate(*a);
}
is any more "untypical" or less "clear" than
for (i = 0; i < n; i++) {
frobnicate(a[i]);
}

>You've answered your own question.
Example 1 is incorrect.

I don't think a typo in an example proves much. He could have typed,
say, a[n] in the second case and it would have been just as wrong.

-- Richard
--
:wq

[Malcolm McLean]

"Paul Hsieh" <we******@gmail.comwrote in message

On Jan 22, 4:10 am, "Bart C" <[e-mail]:

>"Malcolm McLean" <[e-mail] in message

I think that's what Malcolm's original point was. Structs, pointers
and arrays are really just the building blocks for real data
structures.

Unfortunately, a single flat record sequence (i.e., a struct) is also
a data structure, so I don't think his distinction is precise enough.

You could argue it is. A floating point number is also a "data structure" on
that definition, since it has a flag, an exponent, and a mantissa.

In general terms, by "data structure" we don't mean "a type of struct". We
means "several similar items linked together in some way".

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Army1987]

jacob navia wrote:

I mean if I have some data (like 45 000) how the hell I am supposed to
know if the implementation supports that unless I use can hold that?

I cannot parse the second half of the sentence, but what's wrong with
`long n = 45000; ` or `unsigned n = 45000; `?

--
Army1987 (Replace "NOSPAM" with "email")

[Flash Gordon]

Malcolm McLean wrote, On 24/01/08 13:12:

>
"Paul Hsieh" <we******@gmail.comwrote in message

>On Jan 22, 4:10 am, "Bart C" <[e-mail]:

>>"Malcolm McLean" <[e-mail] in message

I think that's what Malcolm's original point was. Structs, pointers
and arrays are really just the building blocks for real data
structures.

Unfortunately, a single flat record sequence (i.e., a struct) is also
a data structure, so I don't think his distinction is precise enough.

You could argue it is. A floating point number is also a "data
structure" on that definition, since it has a flag, an exponent, and a
mantissa.

As I pointed out else-thread some lecture notes refer to integer types
as basic data structures.

In general terms, by "data structure" we don't mean "a type of struct".
We means "several similar items linked together in some way".

A data structure can link a number of dissimilar items together in some
way. If you want an example that is more complex than a C struct then
look at relational databases, specifically joins.

In any case, as there is more than one possible definition of what
qualifies as a "basic data structure" you cannot say what support C has
for them unless you first define what you mean by "basic data structure".
--
Flash Gordon

[Chris Hills]

In article <pM******************************@bt.com>, Malcolm McLean
<re*******@btinternet.comwrites

>My own view is that you should be able to stick to char for characters
and int for integers, in almost every situation. However this is only
tenable if you can use int as both an arbitrary array index and a fast
type.

Signed and unsigned char are integer types.
Plain char is a character type (and the signed/unsigned is
implementation dependant)

there are more 8 bit MCU out there than anything else. They usually use
signed/unsigned char as their base type for most things.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <fm**********@rumours.uwaterloo.ca>,
dj******@csclub.uwaterloo.ca.invalid writes

>In article <6c******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>Flash Gordon said:

>>Personally I don't find underscores in names
a problem for scanning, especially once I have learnt the patterns.

Is ugliness a problem? I guess ugliness is in the eye of the beholder.

For exact-width types, I actually lean toward considering ugliness a
Good Thing.

Most people who think they need exact-width types are wrong, and making
them as ugly and inconvenient as possible discourages their use (which
on the whole is a Good Thing); but when you actually do need them (I've

On embedded systems when you interface to hardware, do bit manipulation
etc
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <Jc******************************@bt.com>, Malcolm McLean
<re*******@btinternet.comwrites

>
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message

>See above, the types you want have been supported for a long time. If
you don't like the spelling you can typedef them to something else.

bool breaks libraries.

If ANSI decides that "s64" shall be the name of a new type, that's
fine.

Only if they get it past the other 30-40 nations defining C

>If I define it myself, either the whole world adopts my convention,
which is to say I have usurrped ANSI / ISO,

You could get them to adopt it.

>it is a nuisance to everybody trying to call or read my code.

No change there then :-))))
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <5v*************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites

>CBFalconer wrote:

>Ian Collins wrote:

>>Richard Heathfield wrote:

.... snip ...

>>>Let me ask you something - do you ignore 1024 bit types if they
are available? How about ignoring 131072 bit types if they are
available? What about 1048576 bit types?
Well the platforms I work on are either POSIX compliant, or I use
a POSIX wrapper over the native API, which provides stdint.h.

The last time I looked the C standard had absolutely no reference
to POSIX. If this was comp.os.posix your comment would have a good
chance of being on topic.

I take it back. It shows up in the bibliography. Once. Still OT.

Does every word posted here have to be in the ISO C standard to meet
with your approval? Read what I was answering.

Ignore him.

There are a small band of zealots on c.l.c who use the C standard like
fundamental Christians read the Bible.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/