Sizes of Integer Types

[Bob Timpkinson]

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

Thanks!

Bob.

[Richard Bos]

Kelsey Bjarnason <kb********@gmail.comwrote:

On Tue, 11 Sep 2007 18:59:20 -0700, Keith Thompson wrote:

One more time, code that uses uint32_t cannot be 100% portable.

Because uint32_t et al are broken beyond redemption and must be avoided at
all costs. Yes, we're agreed.

Kelsey, either you are being deliberately obtuse, or you really _are_ so
stupid that you think the situation is that black-and-white. Either way,
I see no reason to discuss this with you any more.

Richard

[Richard Bos]

Keith Thompson <ks***@mib.orgwrote:

Richard Heathfield <rj*@see.sig.invalidwrites:

Ian Collins said:

Richard Heathfield wrote:
So one must exercise care even in C90 (or accept that one's code is
not portable to certain kinds of implementation). C99 has all of the
C90 portability issues, and adds a whole bunch of new ones.

But availability of fixed wi[d]th types isn't one of them,

It *is*, if people are lured into using C99's named types unnecessarily,
because they (erroneously) believe that this somehow makes their code
more portable than is in fact the case.

Certainly any programmer should understand just what uint32_t is
before using it. As I've said before, it would have made a lot more
sense to call it uint_exact32_t; the simple name it has now just makes
it too tempting to use where it's not really needed.

*But* I think that having (optional) exact-width types is a good idea,
for those fairly rare cases where that happens to be exactly what you
need.

You, sir, hit the nail on the head both times.

Richard

[Chris Hills]

In article <q9******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites

>Chris Hills said:

<snip>

>C99 was not taken up by the industry.

Right. So why bother to argue about it?

I am having to look at where next. Also C99 was partially taken up.
Most compilers are somewhere between C95 and C99

Also MISRA-C is having to decide if we reference C95 or C99 or look at
C2*
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <q9******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites

>Chris Hills said:

<snip>

>The problem with most "religious" debates is the zealots can always
quote a verse (usually out of context) and ignore the bigger picture.

I'm not trying to ignore any bigger pictures. But this isn't about
bigger pictures. This is about whether the draft does or does not say
the same thing as the published Standard

No. It is about the validity of a draft compared to a ratified standard.

>about whether intN_t types are
optional. If it doesn't, fine, I'll eat humble pie and be glad of it,
because I'll have learned something. But right now it seems to me that
you're reading a different published Standard to the one I paid ANSI
for, back in early 2000.

No Idea. I don't use ANSI standards.

>The paragraph in the draft you are looking at may be identical to the
one in the ratified standard BUT other paragraphs in the standard, but
not in the draft, may alter the use of the one paragraph you have
quoted.

Could you please point out the paragraphs in the standard that alter the
meaning of the one paragraph I quoted?

You look. That is the whole point. The draft is probably the same but
may be not. The standard may have other things added(or removed) which
may affect the words that appear to be the same in both.

If "close enough is good enough" for you then there is no point quoting
to the standard or draft. Certainly no validity in getting pedantic
about it.

>
<snip>

>Just because the one paragraph is the same it don't mean a thing.
Especially when the other paragraph in the publish standard, but not
in
the draft, does have a bearing on the paragraph you are quoting...
but you knew that didn't you?

No, I didn't. Perhaps you'd care to elaborate by posting the paragraph
number. (I do have the published Standard, of course, so that will be
sufficient.)

You miss the point. The draft has no authority, may be different and
might have other things that affect the paragraphs that are the same.

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

[Richard Heathfield]

Chris Hills said:

<snip>

BTW Richard... I assume you are happy to use the Koran as the Word of
God as many passages are the same as the Bible? Whole paragraphs....
:-)

Where they are word for word the same? Yes, absolutely. What possible
difference could it make, if the words are the same?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Chris Hills said:

In article <q9******************************@bt.com>, Richard
Heathfield <rj*@see.sig.invalidwrites

>>Ian Collins said:

<snip>

>>>>
ISO 9000.

Oh, *that*. Nah, when the ISO guys came round, we just didn't show
them the contents of our desk drawers. :-)

Would ISO be interested in sandwiches

That's what cafeterias are for.

and old copies of FHM and Loaded?
:-)

More likely "Dr Dobbs", "Program Now", and ".EXE". Sorry to disappoint
you... :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Chris Hills]

In article <MK******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites

>Chris Hills said:

>In article <q9******************************@bt.com>, Richard
Heathfield <rj*@see.sig.invalidwrites

>>>Ian Collins said:

<snip>

>>>>>
ISO 9000.

Oh, *that*. Nah, when the ISO guys came round, we just didn't show
them the contents of our desk drawers. :-)

Would ISO be interested in sandwiches

That's what cafeterias are for.

>and old copies of FHM and Loaded?
:-)

More likely "Dr Dobbs", "Program Now", and ".EXE". Sorry to disappoint
you... :-)

Are any of those still published?

I think Exe has gone.
I had some Program Now once but not seen ay for a while
Dr Dobbs? Is that still going?
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Richard Heathfield]

Chris Hills said:

In article <MK******************************@bt.com>, Richard
Heathfield <rj*@see.sig.invalidwrites

>>Chris Hills said:

>>and old copies of FHM and Loaded?
:-)

More likely "Dr Dobbs", "Program Now", and ".EXE". Sorry to disappoint
you... :-)

Are any of those still published?

Dr Dobbs is still published. The others died a long time ago.
Fortunately, when a print mag returns from main, the output archive is
unaffected.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Charlie Gordon]

"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de news:
MK******************************@bt.com...

Chris Hills said:

<snip>

>BTW Richard... I assume you are happy to use the Koran as the Word of
God as many passages are the same as the Bible? Whole paragraphs....
:-)

Where they are word for word the same? Yes, absolutely. What possible
difference could it make, if the words are the same?

If any words are the same, that would be sheer coincidence, they are not
written in the same tongue, nor even in the same script. Translators can
produce similar translations, but these are not the original Word.

--
Chqrlie.

[Richard Heathfield]

Charlie Gordon said:

"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de
news: MK******************************@bt.com...

>Chris Hills said:

<snip>

>>BTW Richard... I assume you are happy to use the Koran as the Word
of God as many passages are the same as the Bible? Whole
paragraphs....
:-)

Where they are word for word the same? Yes, absolutely. What possible
difference could it make, if the words are the same?

If any words are the same, that would be sheer coincidence, they are
not written in the same tongue, nor even in the same script.

Presumably Chris has a passage in mind where they /are/ the same, and is
prepared to give a reference.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Chris Hills]

In article <fM******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites

>Charlie Gordon said:

>"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de
news: MK******************************@bt.com...

>>Chris Hills said:

<snip>

BTW Richard... I assume you are happy to use the Koran as the Word
of God as many passages are the same as the Bible? Whole
paragraphs....
:-)

Where they are word for word the same? Yes, absolutely. What possible
difference could it make, if the words are the same?

If any words are the same, that would be sheer coincidence, they are
not written in the same tongue, nor even in the same script.

Presumably Chris has a passage in mind where they /are/ the same, and is
prepared to give a reference.

Not to hand but I have in the past when studying the texts found the
same stories... The events and people are the same but the words are
slightly different. Which you would expect since both are translations
and both are AFAIK are more than one translation from the original

If you are interested in the similarities I will dig some out for you,

Also remember that the Old testament is common to the Jews as well.
Should the Jewish book be given priory as it has had fewer translations
and therefore presumably more correct?

There has been a LOT of controversy over the translations of the bible.
Usually done by a Church that was highly political at the time

BTW Please note I am discussing the translations made by mortals (most
with a political axe to grind) NOT disputing anyone's faith or
disparaging the Word of God.

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

[Joachim Schmitz]

"Chris Hills" <ch***@phaedsys.orgschrieb im Newsbeitrag
news:LW**************@phaedsys.demon.co.uk...

In article <fM******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites

>>Charlie Gordon said:

>>"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de
news: MK******************************@bt.com...
Chris Hills said:

<snip>

BTW Richard... I assume you are happy to use the Koran as the Word
of God as many passages are the same as the Bible? Whole
paragraphs....
:-)

Where they are word for word the same? Yes, absolutely. What possible
difference could it make, if the words are the same?

If any words are the same, that would be sheer coincidence, they are
not written in the same tongue, nor even in the same script.

Presumably Chris has a passage in mind where they /are/ the same, and is
prepared to give a reference.

Not to hand but I have in the past when studying the texts found the same
stories... The events and people are the same but the words are slightly
different. Which you would expect since both are translations and both are
AFAIK are more than one translation from the original

If you are interested in the similarities I will dig some out for you,

Also remember that the Old testament is common to the Jews as well. Should
the Jewish book be given priory as it has had fewer translations and
therefore presumably more correct?

Hmm I somehow fail to see how some similaries between Thora, Bible and Koran
are reletad to the equality in (parts of) C standard and -draft.

Hold on: the Buible differs from the Thora by a TC, called the New
Testament...
Or maybe it's more like C89 vs. C99?

Bye, Jojo

[Richard Heathfield]

Chris Hills said:

Richard Heathfield writes

>>Charlie Gordon said:

>>"Richard Heathfield" a écrit...
Chris Hills said:

<snip>

BTW Richard... I assume you are happy to use the Koran as the Word
of God as many passages are the same as the Bible? Whole
paragraphs....
:-)

Where they are word for word the same? Yes, absolutely. What
possible difference could it make, if the words are the same?

If any words are the same, that would be sheer coincidence, they are
not written in the same tongue, nor even in the same script.

Presumably Chris has a passage in mind where they /are/ the same, and
is prepared to give a reference.

Not to hand

Well, when you find one, let me know.

but I have in the past when studying the texts found the
same stories... The events and people are the same but the words are
slightly different.

Then they're not the same words, are they? So (to get back to the
subject of discussion) it's not a good analogy for the draft of C99 and
the final Standard, where (in the case in point) the words /are/ the
same.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Joachim Schmitz]

"Richard Heathfield" <rj*@see.sig.invalidschrieb im Newsbeitrag
news:tK******************************@bt.com...

Chris Hills said:

>Richard Heathfield writes

>>>Charlie Gordon said:
"Richard Heathfield" a écrit...
Chris Hills said:
>
<snip>
>
>BTW Richard... I assume you are happy to use the Koran as the Word
>of God as many passages are the same as the Bible? Whole
>paragraphs....
>:-)
>
Where they are word for word the same? Yes, absolutely. What
possible difference could it make, if the words are the same?

If any words are the same, that would be sheer coincidence, they are
not written in the same tongue, nor even in the same script.

Presumably Chris has a passage in mind where they /are/ the same, and
is prepared to give a reference.

Not to hand

Well, when you find one, let me know.

>but I have in the past when studying the texts found the
same stories... The events and people are the same but the words are
slightly different.

Then they're not the same words, are they? So (to get back to the
subject of discussion) it's not a good analogy for the draft of C99 and
the final Standard, where (in the case in point) the words /are/ the
same.

The more I think about it, the more I like the picture: Thora -C89,
Bible -C99, the difference between katholic and protestants would be a TC
(Martin Luther 95 theses), similar for anglicans (or would they be Visual
C?), and the Koran would be C++...

Bye, Jojo

[Chris Hills]

In article <fc**********@online.de>, Joachim Schmitz
<no*********@schmitz-digital.dewrites

>"Richard Heathfield" <rj*@see.sig.invalidschrieb im Newsbeitrag
news:tK******************************@bt.com...

>Chris Hills said:

>>Richard Heathfield writes
Charlie Gordon said:
"Richard Heathfield" a écrit...
>Chris Hills said:
>>
><snip>
>>
>>BTW Richard... I assume you are happy to use the Koran as the Word
>>of God as many passages are the same as the Bible? Whole
>>paragraphs....
>>:-)
>>
>Where they are word for word the same? Yes, absolutely. What
>possible difference could it make, if the words are the same?
>
If any words are the same, that would be sheer coincidence, they are
not written in the same tongue, nor even in the same script.

Presumably Chris has a passage in mind where they /are/ the same, and
is prepared to give a reference.

Not to hand

Well, when you find one, let me know.

>>but I have in the past when studying the texts found the
same stories... The events and people are the same but the words are
slightly different.

Then they're not the same words, are they? So (to get back to the
subject of discussion) it's not a good analogy for the draft of C99 and
the final Standard, where (in the case in point) the words /are/ the
same.

The more I think about it, the more I like the picture: Thora -C89,
Bible -C99, the difference between katholic and protestants would be a TC
(Martin Luther 95 theses), similar for anglicans (or would they be Visual
C?), and the Koran would be C++...

We had better stop before the The One True Faith of Forth joins in :-)

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

[Kelsey Bjarnason]

[snips]

On Thu, 13 Sep 2007 08:25:44 +0100, Flash Gordon wrote:

Do you REALLY find so hard to understand that some code does not have to
be portable to every system?

Do you REALLY find it so hard to understand that if you're writing code
where you _know_ the sizes involved on the implementation, you don't
_need_ the uint16_t crap in the first place, as people have been writing
this sort of code for 30 years and more without the new types?

Do you REALLY find it so hard to understand that these types offer no real
benefit in this case, and _cannot_ be relied on in pretty much any other
case, rendering them completely worthless?

[Kelsey Bjarnason]

On Wed, 12 Sep 2007 20:47:03 -0400, pete wrote:

Kelsey Bjarnason wrote:

>Unless you use them, at which point your code's portability has gone
straight into the crapper. Yay, C!
Yesterday you were portable across
endless systems, now you're portable across... well...
who the hell knows, because all bets are off.

Now you're portable across implementations that support those types.

What types? The new int types which aren't required to even exist? Yes,
indeed. Portability goes straight down the crapper.

[Kelsey Bjarnason]

[snips]

On Thu, 13 Sep 2007 14:24:15 +1200, Ian Collins wrote:

If your application requires fixed width types, your application
requires fixed with types. Why should giving them a standardised name
make you code less portable? The fixed width requirement has already
restricted its portability.

Much code _could benefit from_ fixed width types, even if it does not
strictly _need_ them. I happen to write code which falls into this
category.

Thanks to the new int types, I have a wonderful new world in which my code
can be simpler and more efficient in the general case, while possibly
relying on slower emulated types in the oddball case, but trading that off
against reduced code complexity and reduced memory overhead.

This would be a *wonderful* set of affairs, and the new int types make it
all happen - 8 bit integer types, 16 bit integer types, 32 bit integer
types, life is good.

Except it ain't, because when the code compiles on implementation X, the
very types which make life so much better _do not exist_.

Two choices:

1) Simply suck it up and accept that _C_ code will no long work on
anything but the restricted set of machines providing the exact set of
integer types you want (so much for portability)

2) Write the program so it doesn't rely on things which aren't going to
exist (so much for int types)

Since there is very little justification, particularly in most of the code
I write, to limit its migration from system to system, restricting the
code to a comparative hatful of systems is silly. Thus my only option is
to skip the int types.

This forces me to ask the reason they exist. Someone has opined it is for
those cases - few though they may be - where you're working on a
restricted set of implementations, writing something like, oh, device
drivers, where having a 32-bit type would be a boon.

Well, yes, I agree; in those cases, having a 32-bit type would be a boon.
Further, on those systems, we know _a_ type must be 32 bits, or the new
int types wouldn't work, and guess what? People have been writing just
this sort of code on just that sort of system for decades, without the use
of the new int types.

These things _could_ have been made appealing, _could_ have been made
reliable, _could_ have been made actually useful. Instead they were
dropped in in a manner which renders them, in every case I've seen
discussed thus far, either completely valueless or at best of the trivial
value of saving the developer writing a typedef.

Neither of those are sufficient justification, IMO, for including such a
half-baked notion to be enshrined in the standard, yet there they are. So
again, I ask, *what use are they*?

So far, not one good answer to that has come forth.

[jacob navia]

Kelsey Bjarnason wrote:

[snips]

On Thu, 13 Sep 2007 08:25:44 +0100, Flash Gordon wrote:

>Do you REALLY find so hard to understand that some code does not have to
be portable to every system?

Do you REALLY find it so hard to understand that if you're writing code
where you _know_ the sizes involved on the implementation, you don't
_need_ the uint16_t crap in the first place, as people have been writing
this sort of code for 30 years and more without the new types?

I have a lot of code and there is a lot of code in public domain
software like GTK for instance, where the developer defined
precisely uint16 and uint32 and all those types. They have a
need for it, and the C99 standard defined those types to make
a standard and portable definition for them. In most system that exist
now they will be there, but the standard did not force them to exist
in the case some weird acrchitecture in the futurez does not implement
them.
Your continuous ignorance of this simple fact means that you are
unable to understand that and further discussion with you
is worthless. I have not participated in this thread precisely
because of this, and this will be my last post.

[Kelsey Bjarnason]

On Wed, 12 Sep 2007 17:54:31 -0700, Keith Thompson wrote:

Kelsey Bjarnason <kb********@gmail.comwrites:

>[snips]
On Wed, 12 Sep 2007 11:34:45 -0700, Keith Thompson wrote:

>>Ok, show me how to write a typedef for a signed type that's exactly 32
bits wide, with no padding bits and a 2's-complement representation,
so that I don't have to change the definition for different platforms.

Oh, wait, somebody's already done that for you; it's called uint32_t.

Good. Show me where this is defined on a machine with 64-bit types.
Whoops. Doesn't exist. Next.

Show me where anybody claimed that it's defined on a machine with
64-bit types.

So we're agreed: if you rely on the new int types, you can toss portability
right out the freakin' window, and on the flip side, the "benefit" to
these types is... to avoid writing a typedef.

A language feature of such limited apparent value that it causes this
much discussion is probably a dubious item at best, and when the only
benefit that's been offered thus far is to not have to create your own
typedef, the benefits just do not seem sufficient for this feature to
exist at all.

Meanwhile the downsides are pretty obvious: use the feature, forget
portability, avoid the feature and we just end up with another "auto" or
"gets" - unwanted dross laying about cluttering things up.

[Bart van Ingen Schenau]

Kelsey Bjarnason wrote:

[snips]

On Wed, 12 Sep 2007 19:55:41 +0200, Bart van Ingen Schenau wrote:

>Then please show us your typedef for a type of *exactly* 32 bits on a
system with 9-bit char, 18-bit short, 36-bit int and long and 72-bit
long long.

And your uint32_t exists on a machine with 64-bit types, right?

Nope. Next.

*PLONK*

--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

[Al Balmer]

On Thu, 13 Sep 2007 09:22:30 -0700, Kelsey Bjarnason
<kb********@gmail.comwrote:

>On Wed, 12 Sep 2007 20:47:03 -0400, pete wrote:

>Kelsey Bjarnason wrote:

>>Unless you use them, at which point your code's portability has gone
straight into the crapper. Yay, C!
Yesterday you were portable across
endless systems, now you're portable across... well...
who the hell knows, because all bets are off.

Now you're portable across implementations that support those types.

What types? The new int types which aren't required to even exist? Yes,
indeed. Portability goes straight down the crapper.

You keep saying that. The new types *are* required to exist, if the
implementation can support them. You've been quoted C&V.

If the implementation *can't* support the type you need, all the
#ifdef's in the world won't help.

--
Al Balmer
Sun City, AZ

[Al Balmer]

On Thu, 13 Sep 2007 09:47:44 -0700, Kelsey Bjarnason
<kb********@gmail.comwrote:

>On Wed, 12 Sep 2007 17:54:31 -0700, Keith Thompson wrote:

>Kelsey Bjarnason <kb********@gmail.comwrites:

>>[snips]
On Wed, 12 Sep 2007 11:34:45 -0700, Keith Thompson wrote:
Ok, show me how to write a typedef for a signed type that's exactly 32
bits wide, with no padding bits and a 2's-complement representation,
so that I don't have to change the definition for different platforms.

Oh, wait, somebody's already done that for you; it's called uint32_t.

Good. Show me where this is defined on a machine with 64-bit types.
Whoops. Doesn't exist. Next.

Show me where anybody claimed that it's defined on a machine with
64-bit types.

So we're agreed: if you rely on the new int types, you can toss portability
right out the freakin' window, and on the flip side, the "benefit" to
these types is... to avoid writing a typedef.

If writing a typedef will do the job, then so will the new int type.
The difference is that the new int type will work on *all*
implementations which have *any* suitable type, without needing
conditional compilation, whereas you will have to write different
typedef's for different architectures, and some poor maintainer will
have to figure it out.

--
Al Balmer
Sun City, AZ

[Keith Thompson]

la************@ugs.com writes:
[...]

This might be a good place to note that N1256, an updated draft
incorporating the new TC3, has just been published:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>

Cool, thanks!

Is TC3 itself available? (I got TC1 and TC2 as free downloads from
webstore.ansi.org, but TC3 isn't there yet.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Kelsey Bjarnason]

[snips]

On Thu, 13 Sep 2007 18:25:42 +0000, Al Balmer wrote:

>>What types? The new int types which aren't required to even exist? Yes,
indeed. Portability goes straight down the crapper.

You keep saying that. The new types *are* required to exist

Really? So uint8_t exists on a machine with 64-bit char and short and int
and long? No, it doesn't. Continuing...

>, if the
implementation can support them.

"If". And if it doesn't, they don't exist.

Exactly my point. So we're all agreed. Good.

So I now have new int types which, as I keep - correctly - stating aren't
required to exist, so that using them means portability goes straight down
the crapper.

We *are* all in agreement on this, right?

[Kelsey Bjarnason]

[snips]

On Thu, 13 Sep 2007 18:39:55 +0000, Al Balmer wrote:

If writing a typedef will do the job, then so will the new int type.

Making the new int type at best a convenience.

The difference is that the new int type will work on *all*
implementations which have *any* suitable type

Rather than "on all implementations", where, oh, int and char will
continue to work.

Again, exactly my point. What _could have been_ a wonderfully useful
notion has instead become little more than a way to limit the portability
of the code.

[=?iso-2022-kr?q?Harald_van_D=0E=29=26=0Fk?=]

On Thu, 13 Sep 2007 12:28:10 -0700, Kelsey Bjarnason wrote:

On Thu, 13 Sep 2007 18:39:55 +0000, Al Balmer wrote:

>If writing a typedef will do the job, then so will the new int type.

Making the new int type at best a convenience.

>The difference is that the new int type will work on *all*
implementations which have *any* suitable type

Rather than "on all implementations", where, oh, int and char will
continue to work.

Yes: it will also start working on implementations where int and char
don't work, but some other type does.

[Flash Gordon]

Philip Potter wrote, On 13/09/07 09:15:

Richard Heathfield wrote:

>Flash Gordon said:

>>>So one must exercise care even in C90 (or accept that one's code is
not portable to certain kinds of implementation). C99 has all of the
C90 portability issues, and adds a whole bunch of new ones.
So you are allowed to ignore the portability issues that do not affect
you but those who have different portability requirements are not
allowed to limit themselves to the implementations of interest to you?

ITYM s/to you/to them/

Of course they are. I freely accept that there may be legitimate
reasons for using intN_t - but there /is/ a portability cost, and that
needs to be made very clear. Naturally, those who are prepared to pay
that cost can expect to reap the perceived benefits.

I don't normally make one-line replies but: Hear hear.

I have not been following who thinks what as carefully as I might. If
Richard and you agree than limiting portability by using fixed width
type _where_appropriate_ then I obviously have no argument with you on this.

For what it is worth, I'm going to be converting some more code to use
it because the library in question will be writing the data (or reading
it) to else-where where (sometimes physical files) there is for good
reasons a requirement that the stored value is *exactly* a specific
width. There is already code to deal with endianness, and we would have
major work for other reasons if we ported to other than Windows/*nix, so
this is appropriate. I will convert other parts to use the "fast" types
because I know the source data is no more than a given number of bits,
and at those points speed is the most important thing.
--
Flash Gordon

[jacob navia]

Kelsey Bjarnason wrote:

[snips]

On Thu, 13 Sep 2007 18:25:42 +0000, Al Balmer wrote:

>>What types? The new int types which aren't required to even exist? Yes,
indeed. Portability goes straight down the crapper.

You keep saying that. The new types *are* required to exist

Really? So uint8_t exists on a machine with 64-bit char and short and int
and long? No, it doesn't. Continuing...

>, if the
implementation can support them.

"If". And if it doesn't, they don't exist.

Exactly my point. So we're all agreed. Good.

So I now have new int types which, as I keep - correctly - stating aren't
required to exist, so that using them means portability goes straight down
the crapper.

We *are* all in agreement on this, right?

If the types do not exist, it means the machine can't do any operation
with those types!

With YOUR alternative, you are in the same position. Even if you
invent some typedef for 8 bit ints, if the machine can't DO THAT
this is wrong and must be programmed around with masks!!!!

This means that the NON EXISTENCE of those types allows you
to catch that error at COMPILE TIME!!!

But you go on and on saying nonsense. Incredible!

[Keith Thompson]

Kelsey Bjarnason <kb********@gmail.comwrites:

On Wed, 12 Sep 2007 17:54:31 -0700, Keith Thompson wrote:

>Kelsey Bjarnason <kb********@gmail.comwrites:

>>[snips]
On Wed, 12 Sep 2007 11:34:45 -0700, Keith Thompson wrote:
Ok, show me how to write a typedef for a signed type that's exactly 32
bits wide, with no padding bits and a 2's-complement representation,
so that I don't have to change the definition for different platforms.

Oh, wait, somebody's already done that for you; it's called uint32_t.

Good. Show me where this is defined on a machine with 64-bit types.
Whoops. Doesn't exist. Next.

Show me where anybody claimed that it's defined on a machine with
64-bit types.

So we're agreed: if you rely on the new int types, you can toss portability
right out the freakin' window, and on the flip side, the "benefit" to
these types is... to avoid writing a typedef.

No, we are not agreed. Portability is not a black-and-white thing.
Sometimes portability to a subset of all possible implementations is
good enough.

Writing a typedef for an unsigned type that's exactly 32 bits wide
with no padding bits isn't terribly difficult, but it's not trivial.
Writing a similar typedef for a signed type is probably a little
harder. In fact, Doug Gwyn wrote a C90-compatible version of
<stdint.has part of his "q8" package.

Yes the benefit is avoiding writing a typedef. Actually, it's
avoiding *everyone* writing their own typedefs, with different names
and subtly different meanings -- see "WORD", "u32", "uint32", etc.

You suggest that it would have been better to require all these types
to be supported for all implementations, even if they have to be
emulated. That would have required substantial extra work for
implementers. It might not even be possible to emulate all the
required attributes on some systems; consider a 32-bit type with no
padding bits on a system with CHAR_BIT==9. Requiring them to exist
only where the underlying types already exist was a compromise; in my
opinin, it was a perfectly reasonable one.

A language feature of such limited apparent value that it causes this
much discussion is probably a dubious item at best, and when the only
benefit that's been offered thus far is to not have to create your own
typedef, the benefits just do not seem sufficient for this feature to
exist at all.

Most of the discussion has been in response to your stubborn refusal
to acknowledge the point.

Meanwhile the downsides are pretty obvious: use the feature, forget
portability, avoid the feature and we just end up with another "auto" or
"gets" - unwanted dross laying about cluttering things up.

So don't freaking use it. But please *try* to understand that there
are *degrees* of portability, and that partial portability can be
better than none at all.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ed Jensen]

Kelsey Bjarnason <kb********@gmail.comwrote:

Hmm. I win. My code's running, yours needs porting.

No, you lost.

Someone else did it in 1/4 the time, because they used a sane language
with fixed size primitives in the first place. While you agonized
over every line of code making sure it was portable, they sold one
million copies of their software. They're now living on a private
island in the Pacific. You're still stuck playing language lawyer on
your source code.

I kid! I kid! :)

[Flash Gordon]

Kelsey Bjarnason wrote, On 13/09/07 17:47:

On Wed, 12 Sep 2007 17:54:31 -0700, Keith Thompson wrote:

>Kelsey Bjarnason <kb********@gmail.comwrites:

>>[snips]
On Wed, 12 Sep 2007 11:34:45 -0700, Keith Thompson wrote:
Ok, show me how to write a typedef for a signed type that's exactly 32
bits wide, with no padding bits and a 2's-complement representation,
so that I don't have to change the definition for different platforms.

Oh, wait, somebody's already done that for you; it's called uint32_t.
Good. Show me where this is defined on a machine with 64-bit types.
Whoops. Doesn't exist. Next.

Show me where anybody claimed that it's defined on a machine with
64-bit types.

So we're agreed: if you rely on the new int types, you can toss portability
right out the freakin' window,

NO WE ARE NOT! You are limiting portability, just as you are when you
write a program that uses more than a certain minimal amount of memory,
or when you use networking, or when you use any one of a number of other
things!

and on the flip side, the "benefit" to
these types is... to avoid writing a typedef.

No, to avoid having to write and VERIFY a hole mess of conditional code
to select the correct type INCLUDING on implementations you don't
currently have and INCLUDING verifying that it will correctly fail to
compile on other implementations you don't have.

A language feature of such limited apparent value that it causes this
much discussion is probably a dubious item at best, and when the only
benefit that's been offered thus far is to not have to create your own
typedef, the benefits just do not seem sufficient for this feature to
exist at all.

So anything not useful to you personally is of insufficient benefit to
be worth including. In that case just write your own language with
exactly what you want.

Meanwhile the downsides are pretty obvious: use the feature, forget
portability,

Portability is not a binary concept.

avoid the feature and we just end up with another "auto"

I can see why auto was potentially useful and so in the language at one
point.

or
"gets"

A completely different matter.

- unwanted dross laying about cluttering things up.

Unwanted by *you* does not mean unwanted. In case you have not noticed
from the number of people who do want it, IT IS WANTED. What you want
and find useful does NOT define what others want or find useful.
--
Flash Gordon

[Flash Gordon]

Kelsey Bjarnason wrote, On 13/09/07 17:10:

[snips]

On Thu, 13 Sep 2007 08:25:44 +0100, Flash Gordon wrote:

>Do you REALLY find so hard to understand that some code does not have to
be portable to every system?

Do you REALLY find it so hard to understand that if you're writing code
where you _know_ the sizes involved on the implementation, you don't
_need_ the uint16_t crap in the first place, as people have been writing
this sort of code for 30 years and more without the new types?

Ah, but I don't know in advance *which* of the base types will actually
be the required size, only that there will be one. The C99 standard
saves me from having to write that code. Just as the first assembler
saved people from having to write machine code and the first
higher-level language saved people from having to write assembler. It is
exactly the same thing, saving the developer from having to do some of
the work by putting it on the implementer.

Do you REALLY find it so hard to understand that these types offer no real
benefit in this case, and _cannot_ be relied on in pretty much any other
case, rendering them completely worthless?

You fail to understand that the CAN be relied on to exist in ALL
implementations of interest. However, on SOME of those implementations
the appropriate type would be unsigned char, on others unsigned short,
on others unsigned int. The value is that I don't ahve to worry about
*which* type meets the requirements.

Just because something has no worth to you does NOT mean it has no worth
to others.

You have also yet to answer my question. Will ALL of your code run on
the systems I have used with only 8K of program space, 8K of data space,
and 16 bit char, short and int with a 32 bit long? Are ALL of you
programs small enough to fit? If not, YOU have thrown portability right
out the window, so why are you complaining that others don't want
portability to everything?

If you don't answer this time I will assume that by portability you mean
"portability ONLY to implementations approved by Kelsey Bjarnason" in
which case everything you are saying is completely irrelevant to
everyone else.
--
Flash Gordon

[Flash Gordon]

Kelsey Bjarnason wrote, On 13/09/07 20:28:

[snips]

On Thu, 13 Sep 2007 18:39:55 +0000, Al Balmer wrote:

>If writing a typedef will do the job, then so will the new int type.

Making the new int type at best a convenience.

>The difference is that the new int type will work on *all*
implementations which have *any* suitable type

Rather than "on all implementations", where, oh, int and char will
continue to work.

No it won't, unless just because you compile this application the size
of char suddenly changes. It will compile, yes, but that is not the same
as working.

Again, exactly my point. What _could have been_ a wonderfully useful
notion has instead become little more than a way to limit the portability
of the code.

Portability is not binary. Do you think POSIX specific code is
completely non-portable because it won't run on non-posix systems? If so
you have completely failed to understand what portability means. Fixed
size integer types are exactly the same, as are objects above the
minimum size guaranteed by the standard.

If all code has to be portable to all systems tell me how to port code
for manipulating live video with 1MB per frame on a processor with only
8K of RAM and no communication mechanism fast enough to get 1MB on to it
during one frame.
--
Flash Gordon

[Keith Thompson]

Kelsey Bjarnason <kb********@gmail.comwrites:

[snips]
On Thu, 13 Sep 2007 18:39:55 +0000, Al Balmer wrote:

>If writing a typedef will do the job, then so will the new int type.

Making the new int type at best a convenience.

And what's wrong with convenience?

It's trivial to write your own abs() function. Should it not have
been standardized?

>The difference is that the new int type will work on *all*
implementations which have *any* suitable type

Rather than "on all implementations", where, oh, int and char will
continue to work.

No, int and char will *not* work if you require a type of exactly a
specified size.

Again, exactly my point. What _could have been_ a wonderfully useful
notion has instead become little more than a way to limit the portability
of the code.

No, it's a way to simplify code that's *already* inherently not 100%
portable. Code that *properly* uses the exact-width types is no less
portable than it would have been without them.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[pete]

Flash Gordon wrote:

Portability is not binary.

That's right.
It's defined in terms of "little or no modification".
ISO/IEC 2382-l : 1993

01.04.06
portability (of a program)
The capability of a program to be executed on various types
of data processing systems without converting the program
to a different language and with little or no modification.

--
pete

[Kelsey Bjarnason]

On Thu, 13 Sep 2007 20:54:52 +0000, Ed Jensen wrote:

Kelsey Bjarnason <kb********@gmail.comwrote:

>Hmm. I win. My code's running, yours needs porting.

No, you lost.

Someone else did it in 1/4 the time, because they used a sane language
with fixed size primitives in the first place. While you agonized
over every line of code making sure it was portable, they sold one
million copies of their software. They're now living on a private
island in the Pacific. You're still stuck playing language lawyer on
your source code.

Bah. Do it all in PHP and forget all the hassles. :)

I kid! I kid! :)

Indeed. Still... there's obviously (IMO at least) a problem, but what
really bothers me is that it seems to be a problem introduced by a
solution in search of a problem.

Ah well.

I took one look at these int types more'n a few years back, concluded then
that they were bogus nonsense and haven't seen anything in the most of a
decade since to change that opinion. If they work for others, fine. They
don't work for me.

[Keith Thompson]

pete <pf*****@mindspring.comwrites:

Flash Gordon wrote:

>Portability is not binary.

That's right.
It's defined in terms of "little or no modification".
ISO/IEC 2382-l : 1993

01.04.06
portability (of a program)
The capability of a program to be executed on various types
of data processing systems without converting the program
to a different language and with little or no modification.

Note the phrase "various types of data processing systems". A C
program can be "portable" under this definition if it works with
little or no modification on some subset of conforming C
implementations, even if it doesn't work under all conforming C
implementations -- for example, if it works only under conforming C
implementations that provide a predefined integer type that's exactly
32 bits wide.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Chris Hills said:

Joachim Schmitz wrote:

<snip>

>>The more I think about it, the more I like the picture: Thora -C89,
Bible -C99, the difference between katholic and protestants would be
a TC (Martin Luther 95 theses), similar for anglicans (or would they
be Visual C?), and the Koran would be C++...

We had better stop before the The One True Faith of Forth joins in
:-)

Oh, have they finally finished painting it?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Flash Gordon said:

<snip>

I have not been following who thinks what as carefully as I might.

It shouldn't actually matter, should it?

There is a tendency on Usenet (and, I think, in life in general) to
divide the world into teams, such that if I agree with X about Y, then
it is assumed by (some) others that all of my opinions about Y are the
same as X's opinions about Y. But this is simply not the case, and
there is no reason why it should be.

I agree with Kelsey that intN_t types are completely and utterly useless
(wait, wait!). I also agree with Kelsey that it's no big deal quoting
from a draft in clc. But I am less bullish than Kelsey about other
people using intN_t. Personally, I think it's a mistake to be led down
that path, but hey, maybe - just *maybe* - there's a real use for these
little critters that I haven't thought of, yeah? And some people whose
opinion I respect have suggested that they do in fact find these types
useful. So, even though they seem completely useless *to me*, and even
though I think they are ugly and unnecessary warts, I'm not about to
insist that they're dropped from the language. If they are useful to my
friends, let them stay, warts and all.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Joachim Schmitz]

"Keith Thompson" <ks***@mib.orgschrieb im Newsbeitrag
news:ln************@nuthaus.mib.org...

la************@ugs.com writes:
[...]

>This might be a good place to note that N1256, an updated draft
incorporating the new TC3, has just been published:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>

Cool, thanks!

Is TC3 itself available? (I got TC1 and TC2 as free downloads from
webstore.ansi.org, but TC3 isn't there yet.)

I think I found it:
http://www.open-std.org/jtc1/sc22/wg...docs/n1235.pdf

Bye, Jojo

[Charlie Gordon]

"Al Balmer" <al******@att.neta écrit dans le message de news:
ja********************************@4ax.com...

On Thu, 13 Sep 2007 02:06:56 +0200, "Charlie Gordon"
<ne**@chqrlie.orgwrote:

>>It would have been good to mandate their support on _all_ architectures.
Odd bit sized and non 2's complement machines could emulate them in
software...

For purposes of calculation they could. Probably even for purposes of
satisfying the standard. But there might be times when you actually
need the hardware to be able to write say 16 bits and no more, such as
for writing to a 16-bit memory mapped port, where the adjacent 16 bits
is a different port.

You can't really do that portably. If you need bit addressability to your
hardware, you are beyond the scope of the C language.

>>Such biests are disappearing fast at this time,

They are?

Can you name counter examples ?

Aside from the DS9000 and some surviving Unisys mainframes, no one came up
with real life examples of contemporary architectures with non
twos-complement arithmetics, padding bits, trap values and similar obsolete
crap.

--
Chqrlie.

[Charlie Gordon]

"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...

"Charlie Gordon" <ne**@chqrlie.orgwrites:

>"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...

[...]

>>>
How would you emulate uint8_t (which, remember, must have no padding
bits) on an implementation with CHAR_BIT==9, which therefore cannot
support 8-bit objects?

You do not emulate its representation, but you can emulate its well
defined
arithmetic behaviour with available hardware operations and appropriate
masks, shifts, etc. The compiler is already doing something very similar
for bitfields.

And what if I want to write exactly 8 bits to a binary file?

You cannot write bits to a file, you write bytes.
If your byte is larger than 8 bits, my proposal does not solve you problem,
but helps in producing values that are limited to the 8 bit range without
the need for explicit bit masks.

--
Chqrlie.

[Charlie Gordon]

"Al Balmer" <al******@att.neta écrit dans le message de news:
7n********************************@4ax.com...

On Thu, 13 Sep 2007 11:01:33 +0200, "Charlie Gordon"
<ne**@chqrlie.orgwrote:

>>"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...

>>[...]
How would you emulate uint8_t (which, remember, must have no padding
bits) on an implementation with CHAR_BIT==9, which therefore cannot
support 8-bit objects?

You do not emulate its representation, but you can emulate its well
defined
arithmetic behaviour with available hardware operations and appropriate
masks, shifts, etc. The compiler is already doing something very similar
for bitfields.

Arithmetic isn't everything.

Arithmetic can by relied upon more readily than representation.

--
Chqrlie.

[Keith Thompson]

"Charlie Gordon" <ne**@chqrlie.orgwrites:

"Al Balmer" <al******@att.neta écrit dans le message de news:
ja********************************@4ax.com...

>On Thu, 13 Sep 2007 02:06:56 +0200, "Charlie Gordon"
<ne**@chqrlie.orgwrote:

[...]

>>>Such biests are disappearing fast at this time,

They are?

Can you name counter examples ?

Aside from the DS9000 and some surviving Unisys mainframes, no one
came up with real life examples of contemporary architectures with
non twos-complement arithmetics, padding bits, trap values and
similar obsolete crap.

If I recall correctly, some Cray vector machines have padding bits in
some of their predefined integer types. I haven't had a chance to
play with Cray's newer systems, so I don't know whether this is still
applicable; the systems I'm familiar with are mostly obsolete.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Keith Thompson wrote:

"Charlie Gordon" <ne**@chqrlie.orgwrites:

>"Al Balmer" <al******@att.neta écrit dans le message de news:
ja********************************@4ax.com...

>>On Thu, 13 Sep 2007 02:06:56 +0200, "Charlie Gordon"
<ne**@chqrlie.orgwrote:

[...]

>>>Such biests are disappearing fast at this time,
They are?

Can you name counter examples ?

Aside from the DS9000 and some surviving Unisys mainframes, no one
came up with real life examples of contemporary architectures with
non twos-complement arithmetics, padding bits, trap values and
similar obsolete crap.

If I recall correctly, some Cray vector machines have padding bits in
some of their predefined integer types. I haven't had a chance to
play with Cray's newer systems, so I don't know whether this is still
applicable; the systems I'm familiar with are mostly obsolete.

Well, this confirms the proposition that there are no

>real life examples of contemporary architectures with
non twos-complement arithmetics, padding bits, trap values and
similar obsolete crap.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

Keith Thompson wrote:

>"Charlie Gordon" <ne**@chqrlie.orgwrites:

>>"Al Balmer" <al******@att.neta écrit dans le message de news:
ja********************************@4ax.com...
On Thu, 13 Sep 2007 02:06:56 +0200, "Charlie Gordon"
<ne**@chqrlie.orgwrote:

[...]

>>>>Such biests are disappearing fast at this time,
They are?
Can you name counter examples ?

Aside from the DS9000 and some surviving Unisys mainframes, no one
came up with real life examples of contemporary architectures with
non twos-complement arithmetics, padding bits, trap values and
similar obsolete crap.

If I recall correctly, some Cray vector machines have padding bits in
some of their predefined integer types. I haven't had a chance to
play with Cray's newer systems, so I don't know whether this is still
applicable; the systems I'm familiar with are mostly obsolete.

Well, this confirms the proposition that there are no

>>real life examples of contemporary architectures with
non twos-complement arithmetics, padding bits, trap values and
similar obsolete crap.

No, it doesn't. As I indicated, I don't know whether Cray's newer
systems have integer types with padding bits, so the question is still
open.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[lawrence.jones]

In comp.std.c Keith Thompson <ks***@mib.orgwrote:

>
Is TC3 itself available? (I got TC1 and TC2 as free downloads from
webstore.ansi.org, but TC3 isn't there yet.)

The official version is wending its way through the system and will be
available from ISO, ANSI, and other standards organizations in due
course. In the meantime, as noted elsethread, N1235 is what was
submitted for publication and is available from the committee's web
site:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1235.pdf>

-Larry Jones

Do you think God lets you plea bargain? -- Calvin

[Charlie Gordon]

"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...

"Charlie Gordon" <ne**@chqrlie.orgwrites:

>"Al Balmer" <al******@att.neta écrit dans le message de news:
ja********************************@4ax.com...

>>On Thu, 13 Sep 2007 02:06:56 +0200, "Charlie Gordon"
<ne**@chqrlie.orgwrote:

[...]

>>>>Such biests are disappearing fast at this time,

They are?

Can you name counter examples ?

Aside from the DS9000 and some surviving Unisys mainframes, no one
came up with real life examples of contemporary architectures with
non twos-complement arithmetics, padding bits, trap values and
similar obsolete crap.

If I recall correctly, some Cray vector machines have padding bits in
some of their predefined integer types. I haven't had a chance to
play with Cray's newer systems, so I don't know whether this is still
applicable; the systems I'm familiar with are mostly obsolete.

Cray's current generation systems (XT3) and next generation (XT4) use AMD 64
bit Opteron multi-core chips (up to 30 000 of them !).

--
Chqrlie.

[Charlie Gordon]

"jacob navia" <ja***@jacob.remcomp.fra écrit dans le message de news:
46***********************@news.orange.fr...

Keith Thompson wrote:

>"Charlie Gordon" <ne**@chqrlie.orgwrites:

>>"Al Balmer" <al******@att.neta écrit dans le message de news:
ja********************************@4ax.com...
On Thu, 13 Sep 2007 02:06:56 +0200, "Charlie Gordon"
<ne**@chqrlie.orgwrote:

[...]

>>>>Such biests are disappearing fast at this time,
They are?
Can you name counter examples ?

Aside from the DS9000 and some surviving Unisys mainframes, no one
came up with real life examples of contemporary architectures with
non twos-complement arithmetics, padding bits, trap values and
similar obsolete crap.

If I recall correctly, some Cray vector machines have padding bits in
some of their predefined integer types. I haven't had a chance to
play with Cray's newer systems, so I don't know whether this is still
applicable; the systems I'm familiar with are mostly obsolete.

Well, this confirms the proposition that there are no

real life examples of contemporary architectures with
non twos-complement arithmetics, padding bits, trap values and
similar obsolete crap.

Alas no, it merely does not disprove the conjecture that there are none.

I am calling for examples, and this is not a valid one.
But surely the C99 folks must have had more than a few in mind when they
mulled the Standard.

--
Chqrlie.