size_t problems

[Chris Dollin]

Re: size_t problems

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

[Ed Jensen]

Re: size_t problems

Joe Wright <joewwright@com cast.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.

[pete]

Re: size_t problems

Ed Jensen wrote:

>
Joe Wright <joewwright@com cast.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

[Kelsey Bjarnason]

Re: size_t problems

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

[Ed Jensen]

Re: size_t problems

pete <pfiland@mindsp ring.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?

[Richard Heathfield]

Re: size_t problems

Ed Jensen said:

pete <pfiland@mindsp ring.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

[Kelsey Bjarnason]

Re: size_t problems

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.

[Richard Tobin]

Re: size_t problems

In article <8YudnZjycO6c3E HbnZ2dnUVZ8trin Z2d@bt.com>,
Richard Heathfield <rjh@see.sig.in validwrote:

>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
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Kelsey Bjarnason]

Re: size_t problems

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

[Kelsey Bjarnason]

Re: size_t problems

[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 "engineerin g" 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.

[jacob navia]

Re: size_t problems

Ed Jensen wrote:

pete <pfiland@mindsp ring.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!jer ry

[Richard Heathfield]

Re: size_t problems

Richard Tobin said:

In article <8YudnZjycO6c3E HbnZ2dnUVZ8trin Z2d@bt.com>,
Richard Heathfield <rjh@see.sig.in validwrote:
>

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

[jacob navia]

Re: size_t problems

Richard Tobin wrote:

In article <8YudnZjycO6c3E HbnZ2dnUVZ8trin Z2d@bt.com>,
Richard Heathfield <rjh@see.sig.in validwrote:
>

>>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!jer ry

[Ed Jensen]

Re: size_t problems

Richard Heathfield <rjh@see.sig.in validwrote:

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 "suggestion s for C modifications or extensions" was
specifically included.

[Richard Heathfield]

Re: size_t problems

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