size_t problems

[Richard Tobin]

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

 

[Keith Thompson]

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>).

 

[Malcolm McLean]

Kelsey Bjarnason said:

[snips]

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.

 

[Malcolm McLean]

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.

 

[Keith Thompson]

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.

 

[Malcolm McLean]

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.

 

[jacob navia]

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

 

[Kelsey Bjarnason]

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.

 

[Kelsey Bjarnason]

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.

 

[Mark McIntyre]

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

 

[Chris Torek]

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.)

 

[Richard Heathfield]

Malcolm McLean said:

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.

 

[Mark McIntyre]

What I want to retain from 1982 is the openness to new ideas. The
attitude that doesn't deny change or improvements per se.

Nobody here is averse to new ideas, and its scurrilous to suggest
otherwise.

What many people here /are/ averse to is offtopic discussion. Good
groups filled with serious experts exist to discuss posix extensions
to C, networking, graphics, UI development, specific compilers etc
etc. Theres no NEED to discuss absolutely everything in one place.

--
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

 

[Mark McIntyre]

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

 

[Mark McIntyre]

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

 

[Martin Wells]

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

 

[pete]

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

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.

 

[Malcolm McLean]

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.

 

[Flash Gordon]

Malcolm McLean wrote, On 03/09/07 21:20:

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.

 

[Keith Thompson]

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.

Are you under the impression that posting to comp.std.c constitutes
a formal presentation to the committee?

comp.std.c has no official association with the committee. It's just
a newsgroup that discusses the C standard. Some, but by no means all,
committee members hang out there, but they do so as individuals. You
can post anything you like there, as long as it's topical.

In other words, the way to "discuss it informally among interested
people" is *precisely* to post to comp.std.c.

If you want to present something to the committe, you need to talk to
your national body. I don't know what the procedure for that would
be, but I'm sure you can find out if you're sufficiently interested.