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.
Jan 18 '08
130  6626 
Jack Klein said:
<snip>
Note I am not accusing anyone in particular of being a "predominately
desktop/hosted environment programmer".
Accuse? My dear chap, it's an honour! :-) I will quickly confess to being
precisely what you describe. Whilst I *have* written code specifically for
the embedded world, it forms only a tiny fraction of my experience, which
is mostly in what I still think of as the mainframe/mini/micro world.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
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
recently written otherwise- portable code that does, to handle
serializing and deserializing data structures for storage in files
(portably) or transmission over a network (system-specific)), it's
rather nice to have standardized names rather than having to write (a
subset of) C99's <stdint.hfor every C90 implementation I want to
use.
(ntohl and htonl would be nice to have standardized for the same
reason, though some thought would have to be put into whether they work
on bytes, or octets, or low-octet-of-each-byte, or...)
dave
--
Dave Vandervies dj3vande at eskimo dot com
Waiting at a red light has a secondary purpose which is to let me catch
my breath. Let the fit people become organ donors if they want.
--Peter Corlett in the scary devil monastery
In article <56**********************************@j78g2000hsd. googlegroups.com>,
Paul Hsieh <we******@gmail.comwrote:
>Floating point is a superset of integers.
Counterexample:
--------
dj3vande@buttons:~/clc (0) $ cat fp-int.c
#include <stdio.h>
int main(void)
{
unsigned long in=-3;
float d=in;
unsigned long out=d;
if(in==out)
{
printf("unsigned long -float -unsigned long is not demonstrated to be\n lossy by this example\n");
}
else
{
printf("unsigned long -float -unsigned long is demonstrated to be\n lossy by this example\n");
}
printf("in: %lu\n",in);
printf("float val: %f\n",d);
printf("out: %lu\n",out);
return 0;
}
dj3vande@buttons:~/clc (0) $ gcc -W -Wall -ansi -pedantic -O fp-int.c
dj3vande@buttons:~/clc (0) $ ./a.out
unsigned long -float -unsigned long is demonstrated to be
lossy by this example
in: 4294967293
float val: 4294967296.000000
out: 4294967295
dj3vande@buttons:~/clc (0) $ gcc --version
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--------
dave
--
Dave Vandervies dj3vande at eskimo dot com
Waiting at a red light has a secondary purpose which is to let me catch
my breath. Let the fit people become organ donors if they want.
--Peter Corlett in the scary devil monastery
Paul Hsieh wrote:
Richard Heathfield <r...@see.sig.invalidwrote:
.... snip ...
>
>Why? It's not guaranteed to work. Instead, consider:
long int i = 38700;
which *is* guaranteed to work.
It also might be unnecessarily slow. You are letting the compiler
vendor make decisions for you.
int32_t i = 38700;
is also guaranteed to work, and is totally non-controversial about
what it means or is doing.
No, it isn't. It will fail miserably on a C90 system. Instead all
you need is a quick macro somewhere that will define MYTYPE as int
or long, depending on values in limits.h. This is system
independant, avoids oversized beasts, etc. etc. It doesn't need
sizes that are multiples of 8 either. How are you going to handle
a machine with a 9 bit byte, an 18 bit short, 36 bit int, 72 bit
long? Or other.
--
[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
Ian Collins wrote:
CBFalconer wrote:
.... snip ...
>
>I think you have exagerrated the problem. In general there will
only be one beast where you have to be critical of the exact size.
You should set up your own type, and alias it to the appropriate
standard type by using limits.h and conditional defines. Then
write your code in terms of that type.
Isn't that what <stdint.hdoes for you in a standardised form?
No, because the contents of stdint.h are optional, and you have to
pick one that is both suitable and present. If the machine doesn't
have a suitable type they aren't there. However the types are all
aliases for something in the byte, short, int, long, long long (and
unsigned) group. Use of limits.h allows you to select the optimum
for your situation at compile time, and set an equivalent.
Something like:
#if INT_MAX >= 214748367
# define THETYPE int
#else
# define THETYPE long
#endif
and now the rest of the code only sees the standard types (and
THETYPE). You also have the side benefit of not needing C99,
because C90 will work just fine.
--
[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
Richard Heathfield wrote:
Paul Hsieh said:
.... snip ...
>
>This also seriously affects some algorithms like primality
testing. If you know the size of your integers is less than 36
bits, there are well known fast algorithms that can test for
primality deterministically in finite time.
I'm trying to think of a use for less-than-36-bit primes, and
failing.
How about a program to output all 35 bit primes? :-) Now it can
avoid calculating all those pesky less than 35 bit primes. :-)
--
[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
Ian Collins wrote:
Richard Heathfield wrote:
.... snip ...
>
>Provided, of course, that you are one of those lucky people who
has a conforming C99 compiler. I am not one such.
Or working on a POSIX compliant environment where these types are
required.
How does that remove the need for a C99 compiler? Besides which,
this is c.l.c, and POSIX is not specified in any C standard that I
have seen.
--
[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
Paul Hsieh wrote:
Richard Heathfield <r...@see.sig.invalidwrote:
.... snip ...
>
>If you have C99, you can do that, using long long int. (And if
like me you don't, you can't guarantee that a 64-bit type is
available.)
The way you determine if a 64 integer overflows on a 72 bit
machine is different from how you do it on a 64 bit machine (as
in, the code you write is different). If you want to just do it
one way, it is helpful if you have int64_t, not long long int.
I would suggest reading the appropriate copy of limits.h. In fact,
you can even, with great difficulty, get those values into your
program for examination. Also the compiler.
--
[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
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.
--
[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
CBFalconer wrote:
Ian Collins wrote:
>Richard Heathfield wrote:
.... snip ...
>>Provided, of course, that you are one of those lucky people who
has a conforming C99 compiler. I am not one such.
Or working on a POSIX compliant environment where these types are
required.
How does that remove the need for a C99 compiler?
Because the *platform* will have the stdint.h types defined and any C
compiler on that platform will accept (either by implementing or
ignoring) the subset of C99 features the (POSIX) standard requires
(restrict for example).
Besides which,
this is c.l.c, and POSIX is not specified in any C standard that I
have seen.
I was replying to the assertion that a conforming C99 compiler is
required for the stdint.h types.
--
Ian Collins.
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.
--
Ian Collins.
On Jan 18, 12:58 pm, eule...@gmail.com wrote:
This is the reasoning that has led me to conclude that the
[u]int_(fast|least)N types are more useful than signed char and
[unsigned] (short|int|long|long long). They allow me to state my
entire intent instead of stating only half of it and hoping the other
half works out. Having types that allow me to say "I want the
(fastest|smallest) type that gives me at least N bits" is more useful
than having types that only allow me to say "I want a type that gives
me at least N bits".
When your intent is "I need a value that
holds an integer, and I don't care much about speed
or size", a plain int is ideal. Following
the advice that "pre-mature optimization is the root
of all evil", 99% of the time a programmer finds
themselves in that situation. uint_fast32_t is
great, but if I see it in code, I will assume that
it started life as an unsigned and was changed only
after a *lot* of performance testing indicated
that the change was warranted.
IMO, the [u]int_(fast|least)N types should be
used sparingly, since their use implies
information about the performance characteristics
of the code.
Richard Heathfield wrote:
Paul Hsieh said:
>On Jan 18, 8:32 am, Richard Heathfield <r...@see.sig.invalidwrote:
>>Instead, consider:
long int i = 38700;
which *is* guaranteed to work.
It also might be unnecessarily slow. You are letting the compiler
vendor make decisions for you.
int32_t i = 38700;
is also guaranteed to work, and is totally non-controversial about
what it means or is doing.
Provided, of course, that you are one of those lucky people who has a
conforming C99 compiler. I am not one such.
I'm afraid even on a C99 compiler it's not guaranteed to work.
int_least32_t i = 38700;
or
int_fast32_t i = 38700;
are both guaranteed, but Paul Hsieh's original composition is not.
On Jan 18, 7:13 pm, Paul Hsieh <websn...@gmail.comwrote:
On Jan 18, 3:32 am, Richard Heathfield <r...@see.sig.invalidwrote:
Bart C said:
How can one program without knowing the bitsize of one's datatypes?
We know the minimum value range of our data types - why would we need to
know more than that?
You want to do math in a ring, without knowing what ring you are in?
When dealing with signed types, there
is no ring in sight since overflow results
in UB.
CBFalconer wrote, On 19/01/08 02:32:
Ian Collins wrote:
>CBFalconer wrote:
... snip ...
>>I think you have exagerrated the problem. In general there will
only be one beast where you have to be critical of the exact size.
You should set up your own type, and alias it to the appropriate
standard type by using limits.h and conditional defines. Then
write your code in terms of that type.
Isn't that what <stdint.hdoes for you in a standardised form?
No, because the contents of stdint.h are optional, and you have to
pick one that is both suitable and present. If the machine doesn't
have a suitable type they aren't there. However the types are all
aliases for something in the byte, short, int, long, long long (and
unsigned) group. Use of limits.h allows you to select the optimum
for your situation at compile time, and set an equivalent.
Something like:
#if INT_MAX >= 214748367
# define THETYPE int
#else
# define THETYPE long
#endif
If that is your requirement use the int_least or int_fast types. These
are required to be provided for 8, 16, 32 and 64 bits. However, that is
not what Ian was talking about.
and now the rest of the code only sees the standard types (and
THETYPE). You also have the side benefit of not needing C99,
because C90 will work just fine.
Of you write a replacement for stdint.h for the implementations you care
about that do not have it.
--
Flash Gordon
Philip Potter said:
Richard Heathfield wrote:
>Paul Hsieh said:
<snip>
>>>
int32_t i = 38700;
is also guaranteed to work, and is totally non-controversial about
what it means or is doing.
Provided, of course, that you are one of those lucky people who has a
conforming C99 compiler. I am not one such.
I'm afraid even on a C99 compiler it's not guaranteed to work.
Oh, of course - support for intN_t is optional (subject to terms and
conditions). Thank you for the correction.
int_least32_t i = 38700;
or
int_fast32_t i = 38700;
are both guaranteed, but Paul Hsieh's original composition is not.
<nod>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
"Ian Collins" <ia******@hotmail.comwrote in message
Malcolm McLean wrote:
>>
"jacob navia" <ja***@nospam.comwrote in message
>>>
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!
The question is, why do you want an integer equal to 45000?
We can thinks of lots of possible reasons, but a good one might be that
you have 45000 customer records you wish to read into memory.
Which means that you need 45000 * N bytes of contiguous storage, which
most machines will happily provide for fairly reasonable values of N.
But not 16 bit machines.
As long as int is the same as a pointer and memory space is flat,
everything is fine.
Even on a 16 bit machine where int is the same as a pointer and memory
space is flat? You appear to have contradicted yourself.
The program in this case exceeds the capaciticites of the machine.
Of course you can write any program to farm out data to backing store and
thus run on any machine whatsoever, but it is seldom sensible to do so.
Obviously if the number 45000 doesn't refer to a count of things in memory
the logic won't hold.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
"CBFalconer" <cb********@yahoo.comwrote in message
news:47***************@yahoo.com...
Paul Hsieh wrote:
>Richard Heathfield <r...@see.sig.invalidwrote:
... snip ...
>>
>>Why? It's not guaranteed to work. Instead, consider:
long int i = 38700;
which *is* guaranteed to work.
It also might be unnecessarily slow. You are letting the compiler
vendor make decisions for you.
int32_t i = 38700;
is also guaranteed to work, and is totally non-controversial about
what it means or is doing.
No, it isn't. It will fail miserably on a C90 system. Instead all
you need is a quick macro somewhere that will define MYTYPE as int
or long, depending on values in limits.h. This is system
independant, avoids oversized beasts, etc. etc. It doesn't need
sizes that are multiples of 8 either. How are you going to handle
a machine with a 9 bit byte, an 18 bit short, 36 bit int, 72 bit
long? Or other.
Those 18/36-bit systems are really thick on the ground. The only ones I'm
even aware of are long obsolete.
Computers with power-of-two bit sizes seem to be dominant, which must be why
the C99 standard appears to be littered with 8,16,32,64-bit references and
not 9,18,36,72-bit ones.
(The 36-bit machine I used at college was a splendid beast to work with
however. And the bytes were usually 7 bits: 7,18,36,72-bits, much more fun.)
--
Bart
"Ian Collins" <ia******@hotmail.comwrote in message
Richard Heathfield wrote:
>Ian Collins said:
>>So you ignore native 64 bit types if they are available?
If I'm writing portable code, yes, I do. It makes life so much simpler.
My approach (shared by a number of opensource projects, libgd for
example) is to test for 64 bit types and use them at configuration or
build time if they are there.
Then problem with your approach is that you then need to test the code on
two systems. With Richard's, you can develop on your humble PC, even my
horrid Vista system, and know that the results ought to be the same on the
Cray or anything else.
Note that to submit jobs to my supercomputer I have to put them into a
queue. So if I have to wait 3 hours to get a slot, only to find that an
index goes out of range, it's really irritating.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
<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.
It becomes worse when mixing two implementations of C which cannot agree
what they mean by int or long int, on the same hardware.
Maybe CPU manufacturers like Intel should keep the word sizes of their
processors secret to encourage good portable programming.
--
Bart
Paul Hsieh wrote:
You are missing my point. Its not the 4 bits *above* 32 that are the
problem, its the 4 bits *BELOW* 40 that are the problem. If you feed
a 36 bit algorithm with a 40 bit value, then it might not function
correctly.
int isprime(unsigned long long int n)
{
if (n 0xfffffffffULL) {
errno = ERANGE;
return -1;
} else {
/* ... */
if (/* n is prime */ ... ) return 1;
else return 0;
}
}
--
Army1987 (Replace "NOSPAM" with "email")
Malcolm McLean wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
>Malcolm McLean wrote:
>>>
"jacob navia" <ja***@nospam.comwrote in message
If I write
int a = 45000;
[...]
>Even on a 16 bit machine where int is the same as a pointer and
memory
>space is flat? You appear to have contradicted yourself.
The program in this case exceeds the capaciticites of the machine. Of
course you can write any program to farm out data to backing store and
thus run on any machine whatsoever, but it is seldom sensible to do so.
Obviously if the number 45000 doesn't refer to a count of things in
memory the logic won't hold.
Obviously if the number 45000 referred to a count of things in memory it
wouldn't be placed in a signed int.
Just an example:
Supposing ERANGE is 34, if you write errno = ERANGE; there are 34 of
*which*, exactly, in memory?
--
Army1987 (Replace "NOSPAM" with "email")
Ian Collins wrote:
CBFalconer wrote:
>Ian Collins wrote:
>>Richard Heathfield wrote:
.... snip ...
Provided, of course, that you are one of those lucky people who
has a conforming C99 compiler. I am not one such.
Or working on a POSIX compliant environment where these types are
required.
How does that remove the need for a C99 compiler?
Because the *platform* will have the stdint.h types defined and any C
compiler on that platform will accept (either by implementing or
ignoring) the subset of C99 features the (POSIX) standard requires
(restrict for example).
So what? The language (C90) doesn't access them. It does access
short, int, long.
--
[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
Ian Collins wrote:
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.
Well, the thing that makes C code portable is adherance to the C
standard. Since POSIX doesn't really appear there, POSIX dependant
code is not as portable as C code. This group deals with portable
C code. If we fail to advise OT posters of their mistakes, they
will never learn, and the OT posts will run wild.
I believe other groups exist where POSIX is topical.
--
[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
On Sat, 19 Jan 2008 08:19:43 -0500, CBFalconer wrote:
Ian Collins wrote:
>Because the *platform* will have the stdint.h types defined and any C
compiler on that platform will accept (either by implementing or
ignoring) the subset of C99 features the (POSIX) standard requires
(restrict for example).
So what? The language (C90) doesn't access them. It does access short,
int, long.
You're essentially arguing against a claim that C90 implementations that
provide <stdint.has an extension, provide <stdint.h>. Sure, the C90
standard doesn't define what a C90 implementation might define in
<stdint.h>, but if the only C99 dependency of code is <stdint.h>, and the
C90 implementation's extension is compatible with C99's standard header,
then the code will still work as intended.
"Army1987" <ar******@NOSPAM.itwrote in message
Malcolm McLean wrote:
>Obviously if the number 45000 doesn't refer to a count of things in
memory the logic won't hold.
Obviously if the number 45000 referred to a count of things in memory it
wouldn't be placed in a signed int.
Intermediate counts might be negative. For instance we might need more than
10 - 1 per site employees to comply with some regulation. If we have eleven
sites, we need to check that 45000 is greater than -1, which in this case it
comfortably is, as long as you use signed arithmetic. You will very
frequently see int used to hold a count of things in memory in production
code, and frequently it is the right choice.
>
Just an example:
Supposing ERANGE is 34, if you write errno = ERANGE; there are 34 of
*which*, exactly, in memory?
Not all integers count things in memory. In this case a perfectly reasonable
strategy would be to number the errors consecutively and use the number to
index into an array of messages, but in fact the C standard hasn't imposed
that.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
CBFalconer wrote:
Ian Collins wrote:
>CBFalconer wrote:
... snip ...
>>I think you have exagerrated the problem. In general there will
only be one beast where you have to be critical of the exact size.
You should set up your own type, and alias it to the appropriate
standard type by using limits.h and conditional defines. Then
write your code in terms of that type.
Isn't that what <stdint.hdoes for you in a standardised form?
No, because the contents of stdint.h are optional, ...
No, only some of the contents are optional; others are mandatory. The
[u]int_fastN_t and [u]int_leastN_t types are all mandatory for N = 8,
16, 32, and 64, and so are [u]intmax_t. For each mandatory type, the
corresponding macros are also mandatory. For each type not supported,
the corresponding macros are prohibited, which provides an easy way to
perform a compile-time check of which types are supported.
... and you have to
pick one that is both suitable and present. If the machine doesn't
have a suitable type they aren't there.
Oddly enough, when an optional type is not supported, it generally
wouldn't do you much good if the corresponding typedef were provided,
would it? The typedef couldn't actually be used, because the
corresponding type couldn't be implemented. Making it mandatory to
support the actual types would serve only to prohibit conforming
implementations of C on platforms where those types couldn't be
efficiently supported, it would not increase the number of platforms
supporting those types. There's no good reason for an implementation to
leave out any of the <stdint.htypedefs that it could actually support.
... However the types are all
aliases for something in the byte, short, int, long, long long (and
unsigned) group.
No, it is permitted for them to be aliases for extended integer types as
well.
Use of limits.h allows you to select the optimum
for your situation at compile time, and set an equivalent.
Something like:
#if INT_MAX >= 214748367
# define THETYPE int
#else
# define THETYPE long
#endif
Note: in principle, at least, you should be checking INT_MIN as well as
INT_MAX; there is no guaranteed relationship between the two values, and
unless your application is better served by an unsigned type, INT_MIN
should be at least as relevant as INT_MAX.
If your limit does not correspond to the mandatory [u]int_leastN_t
types, then there's some advantage to this approach. When your limit
does correspond to one of those values, (as it does in this case), then
THETYPE should be the same, as the corresponding int_least type, unless
that type is an extended type that's smaller than THETYPE, which
presumably makes it preferable, while still being big enough for your
needs. Why would you prefer THETYPE instead?
and now the rest of the code only sees the standard types (and
THETYPE). You also have the side benefit of not needing C99,
because C90 will work just fine.
That is a real advantage, given the slow adoption of C99. However,
<stdint.his by far one of the easiest of C99's changes to implement,
and it should be implemented by any compiler which has even minimal
support for C99, and it can easily be supported as an extension to C90
implementations.
Even for implementations which don't provide it, there are publicly
available versions of stdint.h that can be used in a C90 context that do
essentially the same thing as your code, thereby allowing you to write
code that will not need that crutch when compiled using implementations
that do natively support <stdint.h>, whether or not they support any
other feature of C99.
CBFalconer <cb********@yahoo.comwrites:
Ian Collins wrote:
>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.
Well, the thing that makes C code portable is adherance to the C
standard. Since POSIX doesn't really appear there, POSIX dependant
code is not as portable as C code. This group deals with portable
C code. If we fail to advise OT posters of their mistakes, they
will never learn, and the OT posts will run wild.
I believe other groups exist where POSIX is topical.
Why don't you butt out of threads to which you offer no input? Ian was
explaining something to someone. It does not need to be vetted by
you. Now, run along about to your thread about cleaning cat litter. I
mean! That is surely on topic because it's YOUR thread eh?
CBFalconer wrote:
Ian Collins wrote:
>CBFalconer wrote:
>>Ian Collins wrote:
Richard Heathfield wrote:
.... snip ...
Provided, of course, that you are one of those lucky people who
has a conforming C99 compiler. I am not one such.
Or working on a POSIX compliant environment where these types are
required.
How does that remove the need for a C99 compiler?
Because the *platform* will have the stdint.h types defined and any C
compiler on that platform will accept (either by implementing or
ignoring) the subset of C99 features the (POSIX) standard requires
(restrict for example).
So what? The language (C90) doesn't access them. It does access
short, int, long.
But the programmer can in a C90 program.
What are you arguing against?
--
Ian Collins.
CBFalconer wrote:
Ian Collins wrote:
>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.
Well, the thing that makes C code portable is adherance to the C
standard. Since POSIX doesn't really appear there, POSIX dependant
code is not as portable as C code. This group deals with portable
C code. If we fail to advise OT posters of their mistakes, they
will never learn, and the OT posts will run wild.
This is pointless nonsense.
I was explaining how I choose to use 64 bit types, I was not discussing
POSIX.
--
Ian Collins.
Malcolm McLean wrote:
>
"Ian Collins" <ia******@hotmail.comwrote in message
>Richard Heathfield wrote:
>>Ian Collins said:
So you ignore native 64 bit types if they are available?
If I'm writing portable code, yes, I do. It makes life so much simpler.
My approach (shared by a number of opensource projects, libgd for
example) is to test for 64 bit types and use them at configuration or
build time if they are there.
Then problem with your approach is that you then need to test the code
on two systems. With Richard's, you can develop on your humble PC, even
my horrid Vista system, and know that the results ought to be the same
on the Cray or anything else.
How so? If a platform is not explicitly listed as having 64 bit types,
the result is exactly the same as Richard's approach.
If it is, the chance of an unexpected bug is greatly reduced, because
the emulation library is not used. Where do think bugs will be, in the
processor's 64 bit instructions, or an emulation library?
--
Ian Collins.
Paul Hsieh said:
On Jan 18, 7:12 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>Paul Hsieh said:
<snip>
Floating point is a superset of integers.
If that is true, then all integers are floating point numbers. You might
consider it worthwhile to indulge in such sophistry, but you just lost
my attention.
Sophistry?!?!
Not only sophistry, but demonstrably false sophistry.
Claim: floating point is a superset of integers;
Consequence: all integers are floating point numbers;
Counter-example: int n = 42; printf(var?"%f\n":"%Lf\n", n);
Behaviour: undefined, because %f requires a double argument (or a float
argument which will be promoted to double), but an int argument is
supplied - and %Lf requires a long double argument, but an int argument is
supplied;
Conclusion: ints are not floats (which would be promoted to double in a
printf call) or doubles or long doubles, and therefore are not floating
point types;
Demonstrandum: QE.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
On Sat, 19 Jan 2008 21:14:44 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:
>Paul Hsieh said:
>On Jan 18, 7:12 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>>Paul Hsieh said:
<snip>
>Floating point is a superset of integers.
If that is true, then all integers are floating point numbers. You might
consider it worthwhile to indulge in such sophistry, but you just lost
my attention.
Sophistry?!?!
Not only sophistry, but demonstrably false sophistry.
Claim: floating point is a superset of integers;
Consequence: all integers are floating point numbers;
Counter-example: int n = 42; printf(var?"%f\n":"%Lf\n", n);
Behaviour: undefined, because %f requires a double argument (or a float
argument which will be promoted to double), but an int argument is
supplied - and %Lf requires a long double argument, but an int argument is
supplied;
Conclusion: ints are not floats (which would be promoted to double in a
printf call) or doubles or long doubles, and therefore are not floating
point types;
Demonstrandum: QE.
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.
Richard Heathfield wrote:
Paul Hsieh said:
>On Jan 18, 7:12 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>>Paul Hsieh said:
<snip>
>>>Floating point is a superset of integers.
If that is true, then all integers are floating point numbers. You might
consider it worthwhile to indulge in such sophistry, but you just lost
my attention.
Sophistry?!?!
Not only sophistry, but demonstrably false sophistry.
Claim: floating point is a superset of integers;
Consequence: all integers are floating point numbers;
Counter-example: int n = 42; printf(var?"%f\n":"%Lf\n", n);
Behaviour: undefined, because %f requires a double argument (or a float
argument which will be promoted to double), but an int argument is
supplied - and %Lf requires a long double argument, but an int argument is
supplied;
Conclusion: ints are not floats (which would be promoted to double in a
printf call) or doubles or long doubles, and therefore are not floating
point types;
Demonstrandum: QE.
I think the above nonsense breaks the record for c.l.c and that
is difficult to do !
with sizeof(int)==4 all 32 bit integers can be exactly represented in
a double. The integers are a subset of floating point.
In mathematics too, N is a subset of R.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
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.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia said:
Richard Heathfield wrote:
>Paul Hsieh said:
>>On Jan 18, 7:12 pm, Richard Heathfield <r...@see.sig.invalidwrote:
Paul Hsieh said:
<snip>
>>>>Floating point is a superset of integers.
If that is true, then all integers are floating point numbers. You
might consider it worthwhile to indulge in such sophistry, but you
just lost my attention.
Sophistry?!?!
Not only sophistry, but demonstrably false sophistry.
Claim: floating point is a superset of integers;
Consequence: all integers are floating point numbers;
Counter-example: int n = 42; printf(var?"%f\n":"%Lf\n", n);
Behaviour: undefined, because %f requires a double argument (or a float
argument which will be promoted to double), but an int argument is
supplied - and %Lf requires a long double argument, but an int argument
is supplied;
Conclusion: ints are not floats (which would be promoted to double in a
printf call) or doubles or long doubles, and therefore are not floating
point types;
Demonstrandum: QE.
I think the above nonsense breaks the record for c.l.c and that
is difficult to do !
I think you're mistaken.
with sizeof(int)==4 all 32 bit integers can be exactly represented in
a double.
Firstly, C does not require sizeof(int)==4. Secondly, C does not require
that a byte has eight bits. If CHAR_BIT is 32 and sizeof(int) is 4, for
example, then ints will have not 32 but 128 bits. An implementation is
certainly free to set doubles and long doubles at, say, 64 bits and ints
at 128 bits. On such systems, it is impossible precisely to represent all
int values as doubles or long doubles.
The integers are a subset of floating point.
For that to be true, integer types would have to be floating-point types,
which they are not. See above.
In mathematics too, N is a subset of R.
We are discussing C, not mathematics.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Richard Heathfield wrote:
Paul Hsieh said:
>Richard Heathfield <r...@see.sig.invalidwrote:
>>Paul Hsieh said:
<snip>
Floating point is a superset of integers.
If that is true, then all integers are floating point numbers.
You might consider it worthwhile to indulge in such sophistry,
but you just lost my attention.
Sophistry?!?!
Not only sophistry, but demonstrably false sophistry.
Oh come on now. Mr Hsieh just demonstrated a way of securing an
object that could be processed by arithmetic instructions and carry
53 bits of integer information on most extant systems. If you
create your own type (possibly an array of two ints) you will have
to create the arithmetic functional procedures, and conversion
methods for i/o. Instead of:
a += b;
you need:
addup(thing *a, thing b);
and so forth.
--
[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
Ian Collins wrote:
CBFalconer wrote:
>Ian Collins wrote:
>>CBFalconer wrote:
Ian Collins wrote:
Richard Heathfield wrote:
>
.... snip ...
>
>Provided, of course, that you are one of those lucky people who
>has a conforming C99 compiler. I am not one such.
>
Or working on a POSIX compliant environment where these types are
required.
How does that remove the need for a C99 compiler?
Because the *platform* will have the stdint.h types defined and any C
compiler on that platform will accept (either by implementing or
ignoring) the subset of C99 features the (POSIX) standard requires
(restrict for example).
So what? The language (C90) doesn't access them. It does access
short, int, long.
But the programmer can in a C90 program.
What are you arguing against?
Using object types that are not universally available on any
machine, thus impeding portability. limits.h allows you to
automatically select a suitable type from short, int, long (maybe
long long) at compile time. The objective is suitable size with
minimum complexity.
--
[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
CBFalconer wrote:
Ian Collins wrote:
>CBFalconer wrote:
>>Ian Collins wrote:
CBFalconer wrote:
Ian Collins wrote:
>Richard Heathfield wrote:
>>
>.... snip ...
>>
>>Provided, of course, that you are one of those lucky people who
>>has a conforming C99 compiler. I am not one such.
>Or working on a POSIX compliant environment where these types are
>required.
How does that remove the need for a C99 compiler?
Because the *platform* will have the stdint.h types defined and any C
compiler on that platform will accept (either by implementing or
ignoring) the subset of C99 features the (POSIX) standard requires
(restrict for example).
So what? The language (C90) doesn't access them. It does access
short, int, long.
But the programmer can in a C90 program.
What are you arguing against?
Using object types that are not universally available on any
machine, thus impeding portability. limits.h allows you to
automatically select a suitable type from short, int, long (maybe
long long) at compile time. The objective is suitable size with
minimum complexity.
Yes, but you can do that in your own stdint.h where the platform does
not provide one (which is what I do).
--
Ian Collins.
"Ian Collins" <ia******@hotmail.comwrote in message
Malcolm McLean wrote:
>>
"Ian Collins" <ia******@hotmail.comwrote in message
>>Richard Heathfield wrote:
Ian Collins said:
So you ignore native 64 bit types if they are available?
If I'm writing portable code, yes, I do. It makes life so much simpler.
My approach (shared by a number of opensource projects, libgd for
example) is to test for 64 bit types and use them at configuration or
build time if they are there.
Then problem with your approach is that you then need to test the code
on two systems. With Richard's, you can develop on your humble PC, even
my horrid Vista system, and know that the results ought to be the same
on the Cray or anything else.
How so? If a platform is not explicitly listed as having 64 bit types,
the result is exactly the same as Richard's approach.
If it is, the chance of an unexpected bug is greatly reduced, because
the emulation library is not used. Where do think bugs will be, in the
processor's 64 bit instructions, or an emulation library?
Richard's code works on char arrays. Unless he's really done a bad job, the
code should work the same on any platform.
The alternative was to test for a 64-bit type, and use it if found. Which
means that you need to test on both 32 and 64 bit machines to a have
reasonable confidence that the functions are correct.
If your 64-bit machine has a turnaround time measured in hours, this is not
impossible, but it is extremely inconvenient.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
"Paul Hsieh" <we******@gmail.comwrote in message
>
His response is actually quite sad. Knowing that you can have this
extended (if not exactly convenient) integer implementation in C is
kind of useful at times when 32 bits just isn't enough, but you need
more portability that systems that implement 64 bits.
double can be used as a big integer with 53 bits of precision. That's a
perfectly simple, valid point.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
Malcolm McLean wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
>Malcolm McLean wrote:
>>>
"Ian Collins" <ia******@hotmail.comwrote in message
Richard Heathfield wrote:
Ian Collins said:
>So you ignore native 64 bit types if they are available?
>
If I'm writing portable code, yes, I do. It makes life so much
simpler.
>
My approach (shared by a number of opensource projects, libgd for
example) is to test for 64 bit types and use them at configuration or
build time if they are there.
Then problem with your approach is that you then need to test the code
on two systems. With Richard's, you can develop on your humble PC, even
my horrid Vista system, and know that the results ought to be the same
on the Cray or anything else.
How so? If a platform is not explicitly listed as having 64 bit types,
the result is exactly the same as Richard's approach.
If it is, the chance of an unexpected bug is greatly reduced, because
the emulation library is not used. Where do think bugs will be, in the
processor's 64 bit instructions, or an emulation library?
Richard's code works on char arrays. Unless he's really done a bad job,
the code should work the same on any platform.
The alternative was to test for a 64-bit type, and use it if found.
Which means that you need to test on both 32 and 64 bit machines to a
have reasonable confidence that the functions are correct.
If your 64-bit machine has a turnaround time measured in hours, this is
not impossible, but it is extremely inconvenient.
Do you test that your machine can do basic integer maths? Sounds a
little paranoid to me.
--
Ian Collins.
Ian Collins <ia******@hotmail.comwrites:
Do you test that your machine can do basic integer maths? Sounds a
little paranoid to me.
At least one C90 compiler has 64-bit extended integer types for
which some basic integer arithmetic operations are broken
(certain shift operations, if I recall correctly), so this isn't
necessarily just raw paranoia.
--
"The expression isn't unclear *at all* and only an expert could actually
have doubts about it"
--Dan Pop
James Kuyper wrote:
Note: in principle, at least, you should be checking INT_MIN as well as
INT_MAX; there is no guaranteed relationship between the two values, and
unless your application is better served by an unsigned type, INT_MIN
should be at least as relevant as INT_MAX.
I think that the stuff in 6.2.6.2 imply that INT_MIN is either -INT_MAX or
-INT_MAX - 1.
--
Army1987 (Replace "NOSPAM" with "email")
Army1987 wrote:
James Kuyper wrote:
>Note: in principle, at least, you should be checking INT_MIN as well as
INT_MAX; there is no guaranteed relationship between the two values, and
unless your application is better served by an unsigned type, INT_MIN
should be at least as relevant as INT_MAX.
I think that the stuff in 6.2.6.2 imply that INT_MIN is either -INT_MAX or
-INT_MAX - 1.
That has been claimed; but I think it relies upon misinterpretation of
6.2.6.2p2. That clause says that it's implementation-defined whether a
particular bit pattern specified by the standard (it's different for 1's
complement than for the other two options) is a trap representation. On
that basis, people have claimed that this is the only bit pattern for a
signed integer type that is permitted to be atrap representation. That
seems like a non-sequitur to me.
It's also been claimed that having any other bit pattern involving value
or sign bits would violate the standard's requirements for the value of
each value and sign bit. Again, I don't see that - it seems to me that
so long as there are non-trap representations where those bits have the
specified value, those requirements are met, regardless of whether there
are also trap representations where those bits don't have that value.
On Sun, 20 Jan 2008 13:26:39 +0000, James Kuyper wrote:
Army1987 wrote:
>James Kuyper wrote:
>>Note: in principle, at least, you should be checking INT_MIN as well
as INT_MAX; there is no guaranteed relationship between the two
values, and unless your application is better served by an unsigned
type, INT_MIN should be at least as relevant as INT_MAX.
I think that the stuff in 6.2.6.2 imply that INT_MIN is either -INT_MAX
or -INT_MAX - 1.
[...]
It's also been claimed that having any other bit pattern involving value
or sign bits would violate the standard's requirements for the value of
each value and sign bit. Again, I don't see that - it seems to me that
so long as there are non-trap representations where those bits have the
specified value, those requirements are met, regardless of whether there
are also trap representations where those bits don't have that value.
The exact wording is:
"Each bit that is a value bit shall have the same value as the same bit
in the object representation of the corresponding unsigned type (if
there are M value bits in the signed type and N in the unsigned type,
then M <= N )."
Are you saying that an implementation is allowed to ignore this "shall"
in some cases not specified by the standard, as long as it respects it in
other cases? If you are, then could you explain to me how such an
implementation is any more conforming than one that allows
puts("Hello, world!");
but not any other arguments to puts? That's a bit of an extreme example,
I'll admit, but I really don't see a fundamental difference between the
two.
CBFalconer <cb********@yahoo.comwrites:
Paul Hsieh wrote:
>Richard Heathfield <r...@see.sig.invalidwrote:
... snip ...
>>
>>Why? It's not guaranteed to work. Instead, consider:
long int i = 38700;
which *is* guaranteed to work.
It also might be unnecessarily slow. You are letting the compiler
vendor make decisions for you.
int32_t i = 38700;
is also guaranteed to work, and is totally non-controversial about
what it means or is doing.
No, it isn't. It will fail miserably on a C90 system. Instead all
you need is a quick macro somewhere that will define MYTYPE as int
or long, depending on values in limits.h. This is system
independant, avoids oversized beasts, etc. etc. It doesn't need
sizes that are multiples of 8 either. How are you going to handle
a machine with a 9 bit byte, an 18 bit short, 36 bit int, 72 bit
long? Or other.
uint_least32_t
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--
CBFalconer <cb********@yahoo.comwrites:
Ian Collins wrote:
>CBFalconer wrote:
>>Ian Collins wrote:
CBFalconer wrote:
Ian Collins wrote:
>Richard Heathfield wrote:
>>
>.... snip ...
>>
>>Provided, of course, that you are one of those lucky people who
>>has a conforming C99 compiler. I am not one such.
>>
>Or working on a POSIX compliant environment where these types are
>required.
>
How does that remove the need for a C99 compiler?
Because the *platform* will have the stdint.h types defined and any C
compiler on that platform will accept (either by implementing or
ignoring) the subset of C99 features the (POSIX) standard requires
(restrict for example).
So what? The language (C90) doesn't access them. It does access
short, int, long.
But the programmer can in a C90 program.
What are you arguing against?
Using object types that are not universally available on any
machine, thus impeding portability. limits.h allows you to
automatically select a suitable type from short, int, long (maybe
long long) at compile time. The objective is suitable size with
minimum complexity.
You cannot choose "an integer type that is usually fastest to operate
with among all the integer types that have at least the specified
width." (C99, 7.18.1.3p1)
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--
Ian Collins wrote:
CBFalconer wrote:
>Ian Collins wrote:
.... snip ...
>>>
What are you arguing against?
Using object types that are not universally available on any
machine, thus impeding portability. limits.h allows you to
automatically select a suitable type from short, int, long (maybe
long long) at compile time. The objective is suitable size with
minimum complexity.
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". 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.
[1] There may not even exist such a file, since the standard allows
the compiler to have all requirements built-in.
--
[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
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, which is okay, since as you say, C99 already
provides <stdint.h>. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: hostmaster |
last post by:
Hi,
I'm quite new to Python and I am reading this book called 'Core Python
Programming' by Wesley J. Chun. I think that this is not a new book but
I believe some of the points are still valid....
|
by: cppsks |
last post by:
What would be the rational for using const with standard types?
const int & OR const unsigned long &
Thanks.
|
by: Boni |
last post by:
Dear all,
how do I convert a .NET integer into System.Uint32 (needed to call external
function)
Thanks,
Boni
|
by: Frederick Gotham |
last post by:
I'd like to discuss the use of signed integers types where unsigned integers
types would suffice.
A common example would be:
#include <cassert>
#include <cstddef>
int...
|
by: Frederick Gotham |
last post by:
I just want to clarify my understanding of arithmetic and comparison
between two different integer types.
Phase (1): Integer Promotion
----------
All of the following types always get...
| | |
by: Roman Mashak |
last post by:
Hello, All!
I often come across in open-source software definitions of standard types
with new names, for example:
typedef char SYS_CHAR;
typedef unsigned short SYS_UINT16;
....
Why not...
|
by: David T. Ashley |
last post by:
I'm writing code which will compile on multiple Windows and multiple *nix
platforms. Some will have 64-bit integers, I believe.
What is my best option to define platform-independent types such...
|
by: ajay2552 |
last post by:
Hi,
I have a query.
All html tags start with < and end with >. Suppose i want to display either '<' or '>' or say some text like '<Company>' in html how do i do it?
One method is to use <,...
|
by: Bob Timpkinson |
last post by:
Hi,
I have a 32-bit machine... Is there anyway I can get gcc to use the
following integer sizes?
char: 8 bits
short: 16 bits
int: 32 bits
long: 64 bits
long long: 128 bits
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| | |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
| | |
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| |
