469,326 Members | 1,331 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,326 developers. It's quick & easy.

size_t problems

I am trying to compile as much code in 64 bit mode as
possible to test the 64 bit version of lcc-win.

The problem appears now that size_t is now 64 bits.

Fine. It has to be since there are objects that are more than 4GB
long.

The problem is, when you have in thousands of places

int s;

// ...
s = strlen(str) ;

Since strlen returns a size_t, we have a 64 bit result being
assigned to a 32 bit int.

This can be correct, and in 99.9999999999999999999999999%
of the cases the string will be smaller than 2GB...

Now the problem:

Since I warn each time a narrowing conversion is done (since
that could loose data) I end up with hundreds of warnings each time
a construct like int a = strlen(...) appears. This clutters
everything, and important warnings go lost.
I do not know how to get out of this problem. Maybe any of you has
a good idea? How do you solve this when porting to 64 bits?

jacob
Aug 29 '07
409 9572
jacob navia wrote:
Chris Dollin wrote:
>Martin Wells wrote:
>>If a machine is 32-bit, shouldn't it access a 32-bit number quicker
than an 8-bit number?

That depends on the machine.

No-one really cares, anyway, not about /a/ 32-bit number. In the case
of Jacob's 20 million people, the question should be whether it's
faster to access 20 million ints or twenty million bytes -- at which
point, such atopical things as caches (presence and size of) and
disc speed (data for the loading of) may matter more than how long
it takes for the machine to mask out the upper 24 bits of a value.

In all cases, caches or not, i/o of 20MB is faster than i/o of 80MB.
`disc speed (data for the loading of)`.

--
Chris "already" Dollin

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

Sep 3 '07 #301
Joe Wright <jo********@comcast.netwrote:
Indeed. I didn't mean to exclude anyone or to include myself imperiously
into "we". I believe comp.lang.c is properly about how to use the C
language, not how to change it.
I guess I consider comp.lang.c an appropriate place to discuss the
future of C. With any luck, the discussions help us better understand
what we want and need, what we want and don't really need, etc. With
even more luck, someone in a position to do something about it might
look at our discussions and help push C in that direction.
Sep 3 '07 #302
Ed Jensen wrote:
>
Joe Wright <jo********@comcast.netwrote:
I believe comp.lang.c is properly about how to use the C
language, not how to change it.

I guess I consider comp.lang.c an appropriate place to discuss the
future of C. With any luck, the discussions help us better understand
what we want and need, what we want and don't really need, etc. With
even more luck, someone in a position to do something about it might
look at our discussions and help push C in that direction.
comp.std.c is for discussing the future of C.

People in positions to do something about it,
do participate in that newsgroup regularly.

--
pete
Sep 3 '07 #303
[snips]

On Sun, 02 Sep 2007 19:00:43 +0100, Malcolm McLean wrote:
>If I were writing such apps, I'd write the body of the code to be as
conforming as possible, meaning it is effectively immune to switching to
a different OS, compiler, or version of a compiler.
What you not uncommonly find is that the actual processing that the app
performs is trivial - maybe it adds a few columns of numbers together and
produces a report.
Excuse?

Right now I'm working on a chess app; virtually all the code is
computational, with nigh-on nil for user interaction.

Recently I've written reporting apps - log processing, for example - which
read and process gigabytes of data, then produce web pages delineating
the results. No user interaction at all.

In fact, in all the coding I've ever done, the vast majority of it was
code to actually _do_ things, which means the code for processing
outweighs the code for interaction by a very large margin.

If you constrain yourself to nothing but toy programs, you'll get a toy
program view of the universe. We don't constrain ourselves this way; we
actually work on programs with some meat to them.
Sep 3 '07 #304
pete <pf*****@mindspring.comwrote:
comp.std.c is for discussing the future of C.
Where can one find the original charters for both comp.lang.c and
comp.std.c?
Sep 3 '07 #305
Ed Jensen said:
pete <pf*****@mindspring.comwrote:
>comp.std.c is for discussing the future of C.

Where can one find the original charters for both comp.lang.c and
comp.std.c?
The comp.lang.c and comp.std.c newsgroups pre-date charters, and have
never had one.

--
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
Sep 3 '07 #306
On Mon, 03 Sep 2007 06:01:20 +0000, Chris Dollin wrote:
Kelsey Bjarnason wrote:
>Any technical book can contain errors. Any can contain mistakes.

In the last two weeks, I discovered a ... bugette ... an
appendix to a software development book, viz, in the description
of converting a regular expression into a state machine, it
could generate multiple redundant states under a plausible reading
of the algorithm.

The bug has been sitting there for thirteen years. So far as I
know, no-one has ever informed the author, which makes me suspect
that either no-one ever used that algorithm, or if they did, they
also saw the fix.

It would have been nice to have noticed it fourteen years ago,
though.
Indeed. As I said - any book can contain errors, and that does not
_necessarily_ reflect poorly upon the book or the author. Authors are
human, tolerance is granted - to a point.

There is a fine line between simple human fallibility and a complete
disregard for anything approaching correctness, and Malcolm, IMO, pole
vaults across that line with abandon.
Sep 3 '07 #307
In article <8Y******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>Where can one find the original charters for both comp.lang.c and
comp.std.c?
>The comp.lang.c and comp.std.c newsgroups pre-date charters, and have
never had one.
That depends what you mean by a charter. net.lang.c had a statement
of its purpose when it was created.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Sep 3 '07 #308
[snips]

On Sun, 02 Sep 2007 20:21:55 +0100, Malcolm McLean wrote:
Harald van Dijk found one, I found another, so can you find a third?
Actually, I believe I have pointed out errors in stuff posted by Good
Mister Heathfield on more than one occasion.
Sep 3 '07 #309
[snips]

On Sun, 02 Sep 2007 19:33:13 +0100, Malcolm McLean wrote:
>1) Forcing 16-bit implementations to limit allocations to 32767 or fewer
bytes
Or forcing someone in the unusual situation of allocating more than half of
the address space in one go into using an unusual type.
Say what? There's nothing unusual about size_t; it has existed for
nigh-on two decades.
Engineering doesn't usually offer perfect solutions.
Correct. Your "engineering" takes a perfectly viable, if not perfect
solution and breaks it for no benefit other than to make you happy.
If you want to
simulataneously have signed arithemetic, an efficient integer
representation, and use all bits of the integer, something has got to
give.
Where does C guarantee anything about "use all bits of the integer"?
What, you've never heard of "value bits"?

So what we're dealing with here is not the issues you cite, but rather two
issues:

1) Having an efficient (signed or sign-able) integer type
2) Having a type capable of doing the necessary jobs

These two are, demonstrably, not the same thing, so there have to be at
least two types. We have those: int and size_t.

See how that works? Two requirements, two types.
The ability to manipulate huge arrays of bytes, without using a
"special" type, is the thing that should give.
Works for me. Oh, wait, we *do* have a special type; it's called size_t.
The very thing you want to eradicate. But you're arguing that we _need_
such a thing here. Can't have it both ways.
That's not to say you
won't be able to come up with some real examples of situations where it
is extremely inconvenient. Engineering is like that. There's always
someone who wants screws with non-standard threads.
And in this case, that would be you, trying to subvert something which
works well enough to be useful, which has been used for 17 or more years
*precisely because* it is useful, all because it offends some weird
personal sense of rightness.

Leave the personal aesthetics out of it and present a cogent objective
argument for getting rid of the type... *without* either breaking reams of
existing code or imposing limits which don't currently exist - such as no
longer being able to do perfectly legitimate allocations or requiring the
implementation to produce wildly inefficient results.
Sep 3 '07 #310
Ed Jensen wrote:
pete <pf*****@mindspring.comwrote:
>comp.std.c is for discussing the future of C.

Where can one find the original charters for both comp.lang.c and
comp.std.c?
Here it is:

eagle!jerry
Newsgroups : net.news.group, net.lang.c
From : eagle!jerry
Date : Fri Oct 22 01:28:04 1982
Local : Ven 22 oct 1982 01:28
Subjet : C language newsgroup started

My suggestion for a "C" newsgroup met with support and no
opposition so net.lang.c (note lower case) has been created.

It's purpose is to carry on discussion of C programming and
the C programming language. Appropriate topics are

Queries on how to write something in C
Queries about why some C code behaves the way it does
Suggestions for C modifications or extensions
C coding "tricks"
Compiler bugs
Availability of compilers
etc.

Jerry Schwarz
BTL -- Murray Hill
harpo!eagle!jerry
Sep 3 '07 #311
Richard Tobin said:
In article <8Y******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>>Where can one find the original charters for both comp.lang.c and
comp.std.c?
>>The comp.lang.c and comp.std.c newsgroups pre-date charters, and have
never had one.

That depends what you mean by a charter. net.lang.c had a statement
of its purpose when it was created.
Indeed. Note, however, that it was created a very long time ago,
pre-dating many other newsgroups that have since been created and that
have subsumed many of the originally proposed topics of discussion. The
existence of those groups obviates the necessity for this group to
continue to be used for discussing those topics. What remains?
Discussions about programming in the C language - which is what we *do*
discuss.

--
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
Sep 3 '07 #312
Richard Tobin wrote:
In article <8Y******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>>Where can one find the original charters for both comp.lang.c and
comp.std.c?
>The comp.lang.c and comp.std.c newsgroups pre-date charters, and have
never had one.

That depends what you mean by a charter. net.lang.c had a statement
of its purpose when it was created.

-- Richard
Yes, and I have posted that many times. Here is it again:

eagle!jerry
Newsgroups : net.news.group, net.lang.c
From : eagle!jerry
Date : Fri Oct 22 01:28:04 1982
Local : Ven 22 oct 1982 01:28
Subjet : C language newsgroup started

My suggestion for a "C" newsgroup met with support and no
opposition so net.lang.c (note lower case) has been created.

It's purpose is to carry on discussion of C programming and
the C programming language. Appropriate topics are

Queries on how to write something in C
Queries about why some C code behaves the way it does
Suggestions for C modifications or extensions
C coding "tricks"
Compiler bugs
Availability of compilers
etc.

Jerry Schwarz
BTL -- Murray Hill
harpo!eagle!jerry
Sep 3 '07 #313
Richard Heathfield <rj*@see.sig.invalidwrote:
The comp.lang.c and comp.std.c newsgroups pre-date charters, and have
never had one.
The closest thing I could find was an article written by the person
that got the ball rolling. Topics that were explicitly written as
appropriate include:

* Queries on how to write something in C

* Queries about why some C code behaves the way it does

* Suggestions for C modifications or extensions

* C coding "tricks"

* Compiler bugs

* Availability of compilers

It appears "suggestions for C modifications or extensions" was
specifically included.
Sep 3 '07 #314
Kelsey Bjarnason said:
[snips]

On Sun, 02 Sep 2007 20:21:55 +0100, Malcolm McLean wrote:
>Harald van Dijk found one, I found another, so can you find a third?

Actually, I believe I have pointed out errors in stuff posted by Good
Mister Heathfield on more than one occasion.
I don't doubt it, for I am far from infallible - but I think Malcolm was
referring to the program I showed upthread as being a (mildly flawed)
example of a program that seems portable on the surface, but which
contains a handful of non-portable assumptions.

Harald van Dijk found a bug in the code. Malcolm claims he found
another, but I can't find any reference to it. Malcolm /may/ have meant
that he has identified one of the non-portable assumptions.

--
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
Sep 3 '07 #315
Ed Jensen wrote:
Richard Heathfield <rj*@see.sig.invalidwrote:
>The comp.lang.c and comp.std.c newsgroups pre-date charters, and have
never had one.

The closest thing I could find was an article written by the person
that got the ball rolling. Topics that were explicitly written as
appropriate include:

* Queries on how to write something in C

* Queries about why some C code behaves the way it does

* Suggestions for C modifications or extensions

* C coding "tricks"

* Compiler bugs

* Availability of compilers

It appears "suggestions for C modifications or extensions" was
specifically included.
YES!

But according to Heathfield and co, this is now forbidden because...

Well, because they decided so.

Sep 3 '07 #316
Ed Jensen said:
Richard Heathfield <rj*@see.sig.invalidwrote:
>The comp.lang.c and comp.std.c newsgroups pre-date charters, and have
never had one.

The closest thing I could find was an article written by the person
that got the ball rolling. Topics that were explicitly written as
appropriate include:

* Queries on how to write something in C
Still appropriate here.
* Queries about why some C code behaves the way it does
Still appropriate here.
* Suggestions for C modifications or extensions
comp.std.c has subsumed this topic.
* C coding "tricks"
Still appropriate here (albeit considered silly).
* Compiler bugs
Even niche compilers tend to have their own newsgroups now, which have
subsumed this topic.
* Availability of compilers
I may be in a minority here, but I think this is still topical in
comp.lang.c.
It appears "suggestions for C modifications or extensions" was
specifically included.
The comp.std.c newsgroup has since been created for discussing C
modifications and the codification of extensions.
--
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
Sep 3 '07 #317
On Mon, 03 Sep 2007 19:32:47 +0200, jacob navia wrote:
My suggestion for a "C" newsgroup met with support and no
opposition so net.lang.c (note lower case) has been created.
I can't help but notice that net.lang.c isn't the group we're having this
discussion in.

B.
Sep 3 '07 #318
>Richard Tobin wrote:
>That depends what you mean by a charter. net.lang.c had a statement
of its purpose when it was created.
In article <46**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>Yes, and I have posted that many times. Here is it again:
[some snippage]
>Date : Fri Oct 22 01:28:04 1982
Suggestions for C modifications or extensions
Feel free to post that sort of thing in *net* dot lang dot c (but,
please, not *comp* dot lang dot c). :-)

Seriously, the USENET world was rather different in 1982 (as was
the C language, for that matter). On the one hand, you seem to
want change; and yet here, on the other, you want us to pretend it
is still 1982. I find this ... curious.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Sep 3 '07 #319
Martin Wells wrote:
jacob:
>This is exactly the problem Malcolm. Your "one size fits all" is
impracticable in the real world: It produces a bloat in all data
structures that do not need 64 bits but can use 16 or even 8.


Oh God I can see where this is going...

>Note that the ages of all humans in the planet fit into an unsigned
char. There is no need to use 64 when 8 will do


For a compiler writer, you seem to know very little about efficiency.

I myself NEVER use anything smaller than an "int" or "unsigned".
Never. Unless memory consumption is a BIG deal.
I guess you've never written a device driver....

--
Ian Collins.
Sep 3 '07 #320
On Tue, 04 Sep 2007 07:28:47 +1200, Ian Collins wrote:
>I myself NEVER use anything smaller than an "int" or "unsigned".
Never. Unless memory consumption is a BIG deal.
I guess you've never written a device driver....
I suspect most of us haven't. I've been sick enough to write them in
shell script, though.

B.
Sep 3 '07 #321

"CBFalconer" <cb********@yahoo.comwrote in message
news:46***************@yahoo.com...
Malcolm McLean wrote:
>>
... snip ...
>>
What you not uncommonly find is that the actual processing that
the app performs is trivial

Apparently you never write anything computationally complex.
Some people can't read. "Not uncommonly" implies that there are some apps
for which this is not true. Of course there are.

However more often than not the complexity of the user interface determines
the amount of effort required to write a program, for desktop apps at least.
Most of what we want to do with computers is computationally quite trivial.
The difficulty is in presenting the information to the user and letting him
manipulate it in an intuitive way.

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

Sep 3 '07 #322
Martin Wells <wa****@eircom.netwrites:
[...]
The C Standard says that "int" and "unsigned" will be the "natural"
integer types, the quickest ones.
It says "natural"; it does *not* say "quickest".

C99 6.2.5p5:

A "plain" int object has the natural size suggested by the
architecture of the execution environment (large enough to contain
any value in the range INT_MIN to INT_MAX as defined in the header
<limits.h>).

--
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"
Sep 3 '07 #323

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:aI******************************@bt.com...
Kelsey Bjarnason said:
>[snips]

On Sun, 02 Sep 2007 20:21:55 +0100, Malcolm McLean wrote:
>>Harald van Dijk found one, I found another, so can you find a third?

Actually, I believe I have pointed out errors in stuff posted by Good
Mister Heathfield on more than one occasion.

I don't doubt it, for I am far from infallible - but I think Malcolm was
referring to the program I showed upthread as being a (mildly flawed)
example of a program that seems portable on the surface, but which
contains a handful of non-portable assumptions.

Harald van Dijk found a bug in the code. Malcolm claims he found
another, but I can't find any reference to it. Malcolm /may/ have meant
that he has identified one of the non-portable assumptions.
If presented as a portable program that will produce correct output on any
conforming implementation, it is bugged, because an array of UCHAR_MAX is
not guaranteed to fit in available stack space, sorry, automatic memory.
However if you restrict it to 8 bit char platforms, by far the most common,
it is OK.

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

Sep 3 '07 #324

"Joe Wright" <jo********@comcast.netwrote in message
news:9I******************************@comcast.com. ..
Ed Jensen wrote:
I think comp.std.c is the appropriate place to discuss the future of
Standard C.
The campaign for 64 bit ints is a campaign for the future of C, but it is
not a campaign to change the standard.

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

Sep 3 '07 #325
In article <46***********************@news.zen.co.uk>,
Rob Kendrick <nn**@rjek.comwrote:
>I can't help but notice that net.lang.c isn't the group we're having this
discussion in.
Yes it is. The great renaming was (surprise!) a renaming.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Sep 3 '07 #326
jacob navia <ja***@jacob.remcomp.frwrites:
Ed Jensen wrote:
>Richard Heathfield <rj*@see.sig.invalidwrote:
>>The comp.lang.c and comp.std.c newsgroups pre-date charters, and
have never had one.
The closest thing I could find was an article written by the person
that got the ball rolling. Topics that were explicitly written as
appropriate include:
* Queries on how to write something in C
* Queries about why some C code behaves the way it does
* Suggestions for C modifications or extensions
* C coding "tricks"
* Compiler bugs
* Availability of compilers
It appears "suggestions for C modifications or extensions" was
specifically included.

YES!

But according to Heathfield and co, this is now forbidden because...

Well, because they decided so.
Apparently you believe that everything currently discussed in
comp.std.c should instead be discussed in comp.lang.c. Apparently you
believe that comp.std.c should never have been created, and should
have no traffic.

Because you decided so.

--
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"
Sep 3 '07 #327

"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:46***********************@news.orange.fr...
Chris Dollin wrote:
True, everything would be much simpler (this is the reason why
Malcolm advocates this I think), but the lost of flexibility would
be enormous.

Besides, in small machines, C would not even run: it wouldn't have
enough RAM to load the program!
int would be 64 bits. However char would still be an octet and short would
be 16 bits. In practical terms we will also have to introduce a 32 bit type.
However the fact they are not called "int" discourages people from using
them, unless they really need the extra speed or memory efficiency.

The software problem is not usually that processors are not fast enough. It
is that software modules are not sufficiently standardised, leading to
endless reduplication of effort, and erros as parts are fitted together.

However 64 bit ints are not the perfect solution, in the sense that there
are no good arguments agiant them. One of which is that the raison d' etre
of C is a very efficient language. If int is not in fact the most efficent
integer type, that is a big sacrifice to make. However rewritng everything
with size_t's isn't going to solve that problem. There will still be lots of
64 integers in play, but everything else will break, as we have two
standards for a general-purpose integer.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
Sep 3 '07 #328
Keith Thompson wrote:
>
Apparently you believe that everything currently discussed in
comp.std.c should instead be discussed in comp.lang.c. Apparently you
believe that comp.std.c should never have been created, and should
have no traffic.

Because you decided so.
Before a proposal is presented to the standard, it is much better to
discuss it informally among interested people.

THEN, it can be presented to the committee.

jacob
Sep 3 '07 #329
On Mon, 03 Sep 2007 21:09:50 +0100, Malcolm McLean wrote:
"Joe Wright" <jo********@comcast.netwrote in message
news:9I******************************@comcast.com. ..
>Ed Jensen wrote:
I think comp.std.c is the appropriate place to discuss the future of
Standard C.
The campaign for 64 bit ints is a campaign for the future of C, but it is
not a campaign to change the standard.
So how do you ensure C will have 64 bit ints, unless you mandate this in
the standard?

Oh, right, you can't. So it *is* a campaign to change the standard, to
mandate 64-bit ints.

I'm sure all the people using and developing 16-bit, 32-bit and 128-bit
implementations will love this idea.
Sep 3 '07 #330
On Mon, 03 Sep 2007 21:01:33 +0100, Malcolm McLean wrote:
"CBFalconer" <cb********@yahoo.comwrote in message
news:46***************@yahoo.com...
>Malcolm McLean wrote:
>>>
... snip ...
>>>
What you not uncommonly find is that the actual processing that
the app performs is trivial

Apparently you never write anything computationally complex.
Some people can't read. "Not uncommonly" implies that there are some apps
for which this is not true. Of course there are.
The way you wrote it implies that this is in fact commonplace, to find
these apps which do significant interaction and next to zero processing.
Real-world experience in coding many applications of many different types
argues otherwise; apps do a lot of processing and very little interaction,
though the requirements of that interaction may be complex and require
extensive interfaces.
However more often than not the complexity of the user interface
determines the amount of effort required to write a program, for desktop
apps at least.
Really. So a UI which involves little more than, say, calling an
OS-provided file selector dialog - i.e. a very simple UI - implies that
the code which encrypts the selected file requires almost no effort.
Most of what we want to do with computers is
computationally quite trivial.
Says who? Most of what I want to do with computers is computationally
very intensive, but requires little to no user interaction. Simple
example: a chess program. User interaction is very low compared to the
actual effort that goes into the positional analysis. So low, in fact,
the program only occasionally checks for any user interaction at all.
The difficulty is in presenting the
information to the user and letting him manipulate it in an intuitive
way.
That is certainly _a_ challenge. It is by no means the only one.
Sep 3 '07 #331
On Mon, 03 Sep 2007 16:47:06 -0000, in comp.lang.c , Ed Jensen
<ej*****@visi.comwrote:
>pete <pf*****@mindspring.comwrote:
>comp.std.c is for discussing the future of C.

Where can one find the original charters for both comp.lang.c and
comp.std.c?
Comp.lang.c predates the charter system.
No idea about comp.std.c
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Sep 3 '07 #332
Malcolm McLean said:

<snip>
If presented as a portable program that will produce correct output on
any conforming implementation, it is bugged, because an array of
UCHAR_MAX is not guaranteed to fit in available stack space, sorry,
automatic memory. However if you restrict it to 8 bit char platforms,
by far the most common, it is OK.
Thank you for clarifying. That is indeed one of the portability issues
that I knew about when posting that code - i.e. it was one of my
illustrations.

There are at least a couple of others.

--
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
Sep 3 '07 #333
In article <46***********************@news.orange.fr>
jacob navia <ja***@jacob.remcomp.frwrote:
>Before a proposal [for some change to C] is presented to the
standard,
(I think you mean "to whatever committee is standardizing the next
version of C" here, as implied by the below.)
>it is much better to discuss it informally among interested people.

THEN, it can be presented to the committee.
I agree wholeheartedly with this.

The "interested people" are congregated together over in the
newsgroup named "comp.std.c", where they carry on informal
(and sometimes semi-formal) discussions. Sometimes I join them
myself.

(Some of the folks on the committees are sometimes there as well,
but not all of them, and not always. The committee meetings take
place in the real world, rather than on USENET. This tends to make
them expensive, in both time and money. I think it would be better
if at least some future meetings took place at least in part in
cyberspace -- not necessarily "USENET" -- but that is another
problem entirely.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Sep 3 '07 #334
On Mon, 03 Sep 2007 22:21:19 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Before a proposal is presented to the standard, it is much better to
discuss it informally among interested people.
Which is PRECISELY what comp.std.c exists for.
>THEN, it can be presented to the committee.
Yes, quite.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Sep 3 '07 #335
On Mon, 03 Sep 2007 19:39:27 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Ed Jensen wrote:
>>
It appears "suggestions for C modifications or extensions" was
specifically included.


But according to Heathfield and co, this is now forbidden because...
.....subsequently to the above mail being written a quarter of a
century ago, a decision was taken to split discussion about C
programming into several groups, each with a more focussed topic.
>Well, because they decided so.
The group decided so, yes. Thats how democracy works - remember?
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Sep 3 '07 #336
Keith:
It says "natural"; it does *not* say "quickest".

Yes I realised that at the time of posting. I take "natural" to imply
that it's the quickest type for doing arithmetic on and so forth.

....I mean they'd hardly make the "natural" type slower than another
type.

Martin

Sep 3 '07 #337
Ed Jensen wrote:
>
pete <pf*****@mindspring.comwrote:
comp.std.c is for discussing the future of C.

Where can one find the original charters for both comp.lang.c and
comp.std.c?
Don't forget the important part of what I wrote:
People in positions to do something about it,
do participate in that newsgroup regularly.
just in case you feel like making a post in the future
concerning the future of the language
and you want to appear to be serious.

--
pete
Sep 3 '07 #338

"Kelsey Bjarnason" <kb********@gmail.comwrote in message
news:5n************@spanky.localhost.net...
On Mon, 03 Sep 2007 21:09:50 +0100, Malcolm McLean wrote:
>"Joe Wright" <jo********@comcast.netwrote in message
news:9I******************************@comcast.com ...
>>Ed Jensen wrote:
I think comp.std.c is the appropriate place to discuss the future of
Standard C.
The campaign for 64 bit ints is a campaign for the future of C, but it is
not a campaign to change the standard.

So how do you ensure C will have 64 bit ints, unless you mandate this in
the standard?

Oh, right, you can't. So it *is* a campaign to change the standard, to
mandate 64-bit ints.

I'm sure all the people using and developing 16-bit, 32-bit and 128-bit
implementations will love this idea.
No, it's a campaign for people implementing the standard to make int 64
bits, where that is the natural integer size suggested by the architecture.
Or in other words, where an arbitrary index variable needs 64 bits because
the architecture supports huge arrays.

It is not a campaign to change the standard.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
Sep 3 '07 #339
Malcolm McLean wrote, On 03/09/07 21:20:
>
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:46***********************@news.orange.fr...
>Chris Dollin wrote:
True, everything would be much simpler (this is the reason why
Malcolm advocates this I think), but the lost of flexibility would
be enormous.

Besides, in small machines, C would not even run: it wouldn't have
enough RAM to load the program!
int would be 64 bits. However char would still be an octet and short
would be 16 bits. In practical terms we will also have to introduce a 32
bit type.
So you do want the standard changed. That is a discussion for
comp.std.c, although I doubt they will be any more impressed with your
ideas than people are here.
However the fact they are not called "int" discourages people from using
them, unless they really need the extra speed or memory efficiency.
Well, I really need SW developers to use the memory and speed efficiency
because my expensive company notebook is regularly running at 96% memory
usage and very high processor usage and it is not that uncommon for
responsiveness to suffer as a result. So *I* need all major SW
developers for PCs to use the most efficient type and don't want them
discouraged from doing it because it is some new-fangled type than
Malcolm invented but others did not want.
The software problem is not usually that processors are not fast enough.
No, but one of the problems is that SW is too slow and memory hungry.
It is that software modules are not sufficiently standardised, leading
to endless reduplication of effort, and erros as parts are fitted together.
Strange that I am managing to fit together several non-standard
libraries to do the bulk of a complex project. I've probably written
under 10% of the total code in said project.
However 64 bit ints are not the perfect solution,
You've got that right.
in the sense that
there are no good arguments agiant them.
What, none of the arguments used by Intel which I've pointed you at and
you have not addressed are good? How about the arguments you have been
pointed at by those responsible for the Unix standard that you have not
dealt with?
One of which is that the raison
d' etre of C is a very efficient language. If int is not in fact the
most efficent integer type, that is a big sacrifice to make.
Then we had better stick with 32 bit int because that is what Intel say
is most efficient on their spanking new high end 64 bit processors.
However
rewritng everything with size_t's isn't going to solve that problem.
There will still be lots of 64 integers in play, but everything else
will break, as we have two standards for a general-purpose integer.
No, we have one standard for a general purpose integer, one standard for
a general purpose unsigned integer, and one standard for sizes and
indexes. So what you think is a second general purpose integer type
isn't but something you did not even consider is. Perhaps you need to
learn a bit more about C before commenting on it since you still do not
seem to understand it.
--
Flash Gordon
Sep 3 '07 #340
Ed Jensen <ej*****@visi.comwrites:
pete <pf*****@mindspring.comwrote:
>comp.std.c is for discussing the future of C.

Where can one find the original charters for both comp.lang.c and
comp.std.c?
Though comp.lang.c has no charter, the article announcing its creation
(as net.lang.c) has been posted several times in this thread.

I've tried and failed to find the corresonding announcement for
comp.std.c. Perhaps someone else will have better luck. I'd be
interested in reading it.

--
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"
Sep 3 '07 #341
[snips]

On Mon, 03 Sep 2007 22:34:31 +0100, Malcolm McLean wrote:
>So how do you ensure C will have 64 bit ints, unless you mandate this in
the standard?

Oh, right, you can't. So it *is* a campaign to change the standard, to
mandate 64-bit ints.

I'm sure all the people using and developing 16-bit, 32-bit and 128-bit
implementations will love this idea.
No, it's a campaign for people implementing the standard to make int 64
bits, where that is the natural integer size suggested by the architecture.
Or in other words, where an arbitrary index variable needs 64 bits because
the architecture supports huge arrays.
So let me see if I understand.

On a 64-bit implementation, you want ints to be 64-bit, rather than
something else. So far so good.

Your reasoning for this is so that those ints can be used to index memory
regions larger than those index-able by smaller - say 32-bit - ints.

So far so good.

Yet you dislike and want to abolish size_t, which has pretty much as its
sole reason for existence the ability to index memory regions larger than
those index-able by ints.

Hmm. You want to get rid of a type whose apparently sole reason for
existing is to accomplish the very task you want to have accomplished.

This, to you, makes sense?
Sep 3 '07 #342
[snips]

On Mon, 03 Sep 2007 21:06:38 +0000, Richard Heathfield wrote:

Thank you for clarifying. That is indeed one of the portability issues
that I knew about when posting that code - i.e. it was one of my
illustrations.
In a *perfect* example of non-infallibility, I managed to brain fart from
"stack" to "fifo", rather than "lifo" - and have this caught by
a sharp-eyed reader.

Just goes to show, ain't nobody prefect. :)

Also goes to show why having a competent editor is probably a good idea
for an author.
Sep 3 '07 #343
Malcolm McLean wrote, On 03/09/07 22:34:
>
"Kelsey Bjarnason" <kb********@gmail.comwrote in message
news:5n************@spanky.localhost.net...
>On Mon, 03 Sep 2007 21:09:50 +0100, Malcolm McLean wrote:
>>"Joe Wright" <jo********@comcast.netwrote in message
news:9I******************************@comcast.co m...
Ed Jensen wrote:
I think comp.std.c is the appropriate place to discuss the future of
Standard C.

The campaign for 64 bit ints is a campaign for the future of C, but
it is
not a campaign to change the standard.

So how do you ensure C will have 64 bit ints, unless you mandate this in
the standard?

Oh, right, you can't. So it *is* a campaign to change the standard, to
mandate 64-bit ints.

I'm sure all the people using and developing 16-bit, 32-bit and 128-bit
implementations will love this idea.
No, it's a campaign for people implementing the standard to make int 64
bits, where that is the natural integer size suggested by the
architecture.
Well, Intel say not to have a 64 bit int on their 64 bit processor. A
point you have yet to address.
Or in other words, where an arbitrary index variable needs
64 bits because the architecture supports huge arrays.
Actually, that is a distinct issue.
It is not a campaign to change the standard.
If you want the size of int to change on Window, go lobby MS, if you
want it to change on Linux, go lobby the Linux people, if you want it
changed for Posix, go lobby the Posix people. As far as I can see no one
is interested in your ideas here.
--
Flash Gordon
Sep 3 '07 #344
Flash:
Then we had better stick with 32 bit int because that is what Intel say
is most efficient on their spanking new high end 64 bit processors.

Then why are they calling them 64-Bit processors? I can use arrays of
unsigned char's in conjunction with bitwise operators to give the
illusion of 256-Bit numbers on any machine... but that doesn't mean
I'm gonna go calling the machine 256-Bit.

Many 32-Bit machines also have 16-Bit registers, however the 32-Bit
ones are (naturally) more efficient. If the same goes for these
alleged 64-Bit machines, then they should be called 32-Bit.

Martin

Sep 3 '07 #345
Martin Wells <wa****@eircom.netwrites:
Flash:
>Then we had better stick with 32 bit int because that is what Intel say
is most efficient on their spanking new high end 64 bit processors.

Then why are they calling them 64-Bit processors?
Probably because they have 64-bit addresses.

[...]
>
Many 32-Bit machines also have 16-Bit registers, however the 32-Bit
ones are (naturally) more efficient. If the same goes for these
alleged 64-Bit machines, then they should be called 32-Bit.
The "bitness" of a processor has always been a vague concept. There's
a real difference between a processor that can address 2**32 bytes of
(virtual) memory and one that can address 2**64 bytes, even if the
recommended size of int is the same on both.

--
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"
Sep 4 '07 #346
pete <pf*****@mindspring.comwrote:
comp.std.c is for discussing the future of C.

Where can one find the original charters for both comp.lang.c and
comp.std.c?

Don't forget the important part of what I wrote:
>People in positions to do something about it,
do participate in that newsgroup regularly.

just in case you feel like making a post in the future
concerning the future of the language
and you want to appear to be serious.
Thanks, Pete. I added comp.std.c to my (already too large :) list of
newsgroups I read.
Sep 4 '07 #347
Malcolm McLean wrote:
No, it's a campaign for people implementing the standard to make int 64
bits, where that is the natural integer size suggested by the
architecture. Or in other words, where an arbitrary index variable needs
64 bits because the architecture supports huge arrays.
The "natural size" for int on most common 64 bit systems is 32 bits.
Unless you pick a specific definition of "natural" that excludes code
size and performance.

--
Ian Collins.
Sep 4 '07 #348
Flash Gordon wrote:
>
What, none of the arguments used by Intel which I've pointed you at and
you have not addressed are good? How about the arguments you have been
pointed at by those responsible for the Unix standard that you have not
dealt with?
Notice he always avoids responding when these are mentioned. This tends
to the the usual behavior of a troll.

--
Ian Collins.
Sep 4 '07 #349
Martin Wells wrote, On 04/09/07 00:52:
Flash:
>Then we had better stick with 32 bit int because that is what Intel say
is most efficient on their spanking new high end 64 bit processors.

Then why are they calling them 64-Bit processors?
Because they are 64 bit processors.
I can use arrays of
unsigned char's in conjunction with bitwise operators to give the
illusion of 256-Bit numbers on any machine... but that doesn't mean
I'm gonna go calling the machine 256-Bit.

Many 32-Bit machines also have 16-Bit registers, however the 32-Bit
ones are (naturally) more efficient. If the same goes for these
alleged 64-Bit machines, then they should be called 32-Bit.
I believe the main reason for not having a 64 bit int is probably memory
bandwidth and bloat meaning that even though the ALU is as fast for 64
bit numbers as 32 bit numbers overall performance of 64 bit numbers is
slower.
--
Flash Gordon
Sep 4 '07 #350

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

18 posts views Thread by Steffen Fiksdal | last post: by
17 posts views Thread by candy_init | last post: by
5 posts views Thread by edware | last post: by
12 posts views Thread by Alex Vinokur | last post: by
23 posts views Thread by bwaichu | last post: by
318 posts views Thread by jacob navia | last post: by
73 posts views Thread by Yevgen Muntyan | last post: by
89 posts views Thread by Tubular Technician | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by suresh191 | last post: by
reply views Thread by harlem98 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.