size_t problems

[jacob navia]

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

[CBFalconer]

Keith Thompson wrote:

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

.... snip ...

>>
To do that, it has to find an address multiple of four.
Since strings aren't naturally aligned (they could start at
ANY address) it has to make a few comparisons before finding the
right starting address. This means more setup time.

For strings with length less than 80-100 this, together with the
function call, will kill any performance improvements.

When using the optimizer, lcc-win32 generates an inline loop
of 4-5 assembler instructions, comparing character by
character. For relatively short strings, this will beat
any strlen function since the overhead of the function call
is much greater...

There's no reason it couldn't do exactly the same thing for an
explicit call to strlen().

The call itself may be longer than the execution of the inline, for
suitably short strings. And lets face it, 99% of C strings are
short, meaning under 10 chars or so. This is highly system and CPU
specific, and thus really OT here.

Maybe somebody will build a modified strlen routine which keeps
length statistics and install it in his system library. After some
test period that can validate (or invalidate) my claim above.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[jacob navia]

CBFalconer wrote:
[snip]

I advise calming down first.

Excuse me Chuck.

jacob

[Peter J. Holzer]

On 2007-09-02 16:06, CBFalconer <cb********@yahoo.comwrote:

Keith Thompson wrote:

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

>>To do that, it has to find an address multiple of four.

Not necessarily. The library in question is for the Intel architecture,
which allows unaligned access. It is possible that an unaligned access
to a 4-byte word is still faster than 4 accesses to single bytes.

>>For strings with length less than 80-100 this, together with the
function call, will kill any performance improvements.

When using the optimizer, lcc-win32 generates an inline loop
of 4-5 assembler instructions, comparing character by
character. For relatively short strings, this will beat
any strlen function since the overhead of the function call
is much greater...

There's no reason it couldn't do exactly the same thing for an
explicit call to strlen().

The call itself may be longer than the execution of the inline, for
suitably short strings.

Which call? The C compiler could inline any call to strlen. It knows
what it does, after all. Inlining calls to my_strlen is much harder.

(In fact, gcc does not only inline calls to strlen, it replaces calls to
strlen on a string literal with a suitable integer constant).

hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

[Malcolm McLean]

"Tor Rustad" <to********@hotmail.comwrote in message
news:bf*********************@telenor.com...

Malcolm McLean wrote:

>>
"Peter J. Holzer" <hj*********@hjp.atwrote in message
news:sl************************@zeno.hjp.at...

>>On 2007-09-01 19:25, Malcolm McLean <re*******@btinternet.comwrote:

By that kind of reasoning a snail is about as fast as a jet.

The snail, going West, is moving towards the Andromeda galaxy at
50.000001 km/s. The jet, going East, is moving towards Andromeda at about
49.660 km/s, assuming it's a Concorde.

That was a fast snail! :)

AFAIK, M31 is closing in on the Sun at 300 km/s, and on Milky Way at 100
km/s, so how did you arrive at ca. 50 km/s?

That's a wiki fact.
It could easily be wrong. I know Andromeda is moving towards us much faster
than any aeroplance could possibly fly, but I didn't know the value off the
top of my head.

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

[Kelsey Bjarnason]

[snips]

On Thu, 30 Aug 2007 10:03:50 +0100, Malcolm McLean wrote:

In fact if you use size_t safely and consistently, virtually all ints need
to be size_t's.

Complete, total and utter bollocks.

size_t is used primarily for sizes and indexes.
int is used primarily for general calculations.

I have reams of code using both and it is the _unusual_ case where the
twain meet at all.

Where do you get this nonsense?

[jacob navia]

Peter J. Holzer wrote:

On 2007-09-02 16:06, CBFalconer <cb********@yahoo.comwrote:

>Keith Thompson wrote:

>>jacob navia <ja***@jacob.remcomp.frwrites:
To do that, it has to find an address multiple of four.

Not necessarily. The library in question is for the Intel architecture,
which allows unaligned access. It is possible that an unaligned access
to a 4-byte word is still faster than 4 accesses to single bytes.

This will be slower if the address is unaligned.

[snip]

(In fact, gcc does not only inline calls to strlen, it replaces calls to
strlen on a string literal with a suitable integer constant).

I thought about it, but I haven't got the time to do it...

[Kelsey Bjarnason]

[snips]

On Fri, 31 Aug 2007 16:18:18 +0100, Malcolm McLean wrote:

Yes qsort() takes two size_t's as well. So we are OK. The system does work,
but only so long as we are absolutely consistent in using size_t everywhere.

My proposal is to 1) make size_t signed, 2) rename it int.

And thereby break reams of code, and produce yet another situation where
the solution simply does not work.

Current:

void *buff = malloc( 40000U );
int size = 40000;

Oops. The malloc works, but the size is wrong. So your solution requires
either:

1) Forcing 16-bit implementations to limit allocations to 32767 or fewer
bytes

2) Forcing 16-bit implementations to emulate larger ints.
Hmm. Turns out the same problem occurs with 32-bit implementations, as
one can trivially allocate regions 2GB, but a 32-bit int won't work. So
32-bit implementations (and 16-bit ones, too) will have to use 64-bit ints
for everything, making both 32-bit and 16-bit implementations hellishly
inefficient, or simply crippled in terms of memory allocation.

So your proposal is to cripple the language or force it to result in
massively inefficient operations, all because you don't like some feature
which has worked perfectly well for at least some 17 years.

Somehow I think we'll choose to err on the side of sanity on this one; not
a single thing you've offered has given a single real justification for
eradicating size_t, other than to suit your personal pet peeves - and that
might make you happy, but crippling the language to make you happy just
isn't a terribly compelling argument.

[Kelsey Bjarnason]

On Fri, 31 Aug 2007 19:27:00 +0100, Malcolm McLean wrote:

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:sn************@news.flash-gordon.me.uk...

>Malcolm McLean wrote, On 31/08/07 16:18:

>>Yes qsort() takes two size_t's as well. So we are OK. The system does
work, but only so long as we are absolutely consistent in using size_t
everywhere.

Ah, he sees the light.

That's why Basic Algorithms is absolutely consistent in using int.

And producing broken code in the process.

Why you refuse to deal with that side of the equation, I don't know. Yes,
fine, it makes you happy to use int, but it makes your code at best
undesirable and at worst unusable in real programs.

Effectively we are in a hiatus between standards. It looks like C99 will
never be widely implemented. So now is the time to get those nasty
size_t's out of our code.

Now is the time to fix the standard - which means leaving size_t in, as it
actually solves a problem and has a justification for existing, whereas
none of your counter-proposals solve anything or make any sense.

[Kelsey Bjarnason]

[snips]

On Sun, 02 Sep 2007 13:02:38 +0100, Malcolm McLean wrote:

It obviously performs some output, otherwise the program can be optimised to
nothing.

What defines "output"? If I write a program that, oh, takes an argument
specifying a number of seconds to delay, then pauses for that number of
seconds (busy loop or something implementation-specific) before exiting,
what exactly is the output? The return 0 from main? Either way, I would
be most unhappy if a compiler optimized this to nothing - it's not
nothing, it simply does no output in any conventional sense.

[Kelsey Bjarnason]

[snips]

On Sat, 01 Sep 2007 20:16:43 +0100, Malcolm McLean wrote:

No, limited experience, Not the same thing as incompetence at all.

If you write say, mainly code to drive GUIs under Windows, you will find
that there's little point making much portable. Everything has to be ripped
up and rewritten whenever the denizens of Redmond decide to realease a new
compiler anyway.

He said incompetence, and you just demonstrated it.

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.

Some stuff - GUI code, network code, etc - will possibly have to be
rewritten at each change, but if that's a significant portion of the code,
chances are you're doing something very badly wrong.

However if you are writing mostly scientific programs, as I am doing at
present, everything has got to be portable. I've no business writing
code that can't be shifted to a mainframe or PC or whatever, as need
arises.

Oh, you mean like how you use int instead of size_t, thus crippling your
code on 16-bit (and even 32-bit) implementations? That sort of
"portable"?

Even slash slash comments, which I thought were surely as good as
standard by now, are not accepted by the parallel compiler.

Why would you think they're standard? They're in C++ and C99, but most of
the C world uses C90, not C99 - and those are not part of C90, are they?
What, you think standards magically change to suit your whim?

[Kelsey Bjarnason]

On Sun, 02 Sep 2007 12:54:23 +0000, Richard Heathfield wrote:

Malcolm McLean said:

>>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:6e******************************@bt.com...

>>>
Indeed. Everyone makes mistakes. To err is human, and all that.
People are not criticised here for making mistakes, but they *are*
(rightly) criticised for refusing to acknowledge them or to learn
from them.

It would be nice if that were true.

I think it *is* true, by and large. Mistakes *are* pointed out, and
rightly so, but to point out a mistake is *not* the same as to
criticise the person who made it. I make my fair share of mistakes (or
perhaps more!), but when people in clc point this out, I don't feel
threatened or intimidated by the fact. On the contrary, I welcome
corrections for what they really are - opportunities to learn and to
improve my programming.

Yeah, you just tend to make your mistakes so esoteric only about three
people are qualified to find them, let alone figure out the right way. :)

[Malcolm McLean]

"Kelsey Bjarnason" <kb********@gmail.comwrote in message
news:cl************@spanky.localhost.net...

On Sat, 01 Sep 2007 20:16:43 +0100, Malcolm McLean wrote:

>No, limited experience, Not the same thing as incompetence at all.

>If you write say, mainly code to drive GUIs under Windows, you will find

> >that there's little point making much portable. Everything has to be

ripped
up and rewritten whenever the denizens of Redmond decide to realease a >>
new compiler anyway.

He said incompetence, and you just demonstrated it.

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. However the GUI to allow the user to enter these numbers,
check them, specify which columns to add up, and format the report might be
very non-trivial. So in fact the portable bit of the code is a sum()
function and maybe a few histogram or pie chart generators, without the
graphical part.

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

[Kelsey Bjarnason]

On Fri, 31 Aug 2007 21:24:22 +0100, Malcolm McLean wrote:

"Ian Collins" <ia******@hotmail.comwrote in message
news:5j***********@mid.individual.net...

>Malcolm McLean wrote:

>>>
Yes qsort() takes two size_t's as well. So we are OK. The system does
work, but only so long as we are absolutely consistent in using size_t
everywhere.

Isn't consistency one of the foundations of our art?

Yes. But psychological factors are also important.

Indeed, they are. So if you could kindly cease your asinine rantings
against size_t and for 64-bit ints, the rest of us wouldn't have to deal
with it and be happier. Of course, this would also suggest you're going
to fix your currently hopelessly broken code in your book, but I suspect
we'll just have to live with that, reminding newbies of the dangers
inherent in it.

If an index variable
is called "size" then of course the compiler will happily chug through
and index the array by variable "size". However to anyone reading the
program it is intensely irritating.

So don't call it size. Call it index. Just make sure it's a size_t.

If you allow a meaningful, but wrong type, called "int", and a correct
but misleadingly named type, called "size_t", how many programmers are
going to be consistent with their use of size_t.

Those with experience, skill, ability, or simply enough smarts or
curiosity to ask _why_ two different types exist, for starters. Oh, and
any smart enough to ask for more experienced programmers to look over
their code now and then and actually learn from the recommendations
provided.

[Malcolm McLean]

"Kelsey Bjarnason" <kb********@gmail.comwrote in message
news:2j************@spanky.localhost.net...

[snips]

On Fri, 31 Aug 2007 16:18:18 +0100, Malcolm McLean wrote:

>Yes qsort() takes two size_t's as well. So we are OK. The system does
work,
but only so long as we are absolutely consistent in using size_t
everywhere.

My proposal is to 1) make size_t signed, 2) rename it int.

And thereby break reams of code, and produce yet another situation where
the solution simply does not work.

Current:

void *buff = malloc( 40000U );
int size = 40000;

Oops. The malloc works, but the size is wrong. So your solution requires
either:

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.
Engineering doesn't usually offer perfect solutions. If you want to
simulataneously have signed arithemetic, an efficient integer
representation, and use all bits of the integer, something has got to give.
The ability to manipulate huge arrays of bytes, without using a "special"
type, is the thing that should give.
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.

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

[Martin Wells]

jacob navia:

Standard C doesn't have

1) Any serious i/o. To do anything fast you need system specific stuff.
2) Any notion of the keyboard. To handle the keyboard you need system
specific stuff.
3) Any graphics. Ditto.
4) No network.
5) Not any timers with reasonable accuracy.

Good job so that 99% of algorithms don't need any of the above.

C is very popular for systems programming but none of those programs
is written in standard C.

Where possible, I'd hope that they are.

I am porting the lcc-win IDE and debugger. Written in C but system
specific. And I do not give a damm about portability of a windows
debugger to the latest toaster with embedded linux :-)

I don't see what you're smiling about since you've already had a
headache with strlen.

All this people talking about "Portable standard C" are just talking
nonsense.

I've written countless fully-portable C programs.

#include <stdio.h>
int main(void){printf("hello\n");}

is portable since the errors of printf are NOT specified, so you have no
way to know what happened if printf returns a negative result, besides
going into implementation specific stuff!

In the absence of an output error you're guaranteed of the results.
But then how often do we get an output error in such a small program?
0% of the time? Or would it be something considerably bigger like
0.0000000000000000000000000000000000000001% of the time?

Martin

[Martin Wells]

Malcolm:

What are those ints going to be used for? We don't know, but such a useful
function would surely find a place in calculating array indices, or
intermediate values, such as counts, to calculating array indices.

So we need another version

void AddFiveToEachElementsz(size_t *p, size_t len)

The fuse has gone off. That's what the admission of size_t does to your
code.

Sorry I haven't a clue what you're talking about. Could you please
explain more clearly?

Martin

[Martin Wells]

Ed:

But, instead of pointless and unfounded insults, let's try a real
world test for a change. You paste one or two thousand lines of C
code you've written from your most recent project, and we'll see if
anyone on the newsgroup can identify any code that's not 100% portable
C code.

Since you've made the claim that writing 100% portable C code isn't
just easy, but VERY easy, I'm quite sure you're up to the challenge.
It's time to put your code where your mouth is.

Ask me to write an algorithm. Or even an algorithm contained in a very
small program. I'd write it efficiently using fully-portable code.
Something along the lines of the Euro Banknote Serial Number Checker.

Martin

[Martin Wells]

Chris:

Furthermore, the easy-ness of portability varies with the goal of
the code. Clearly, something like "calculate mortgage payments"
or "concatenate files specified by argv[] elements" is going to be
easier than "write an operating system" or "do bitmapped graphics":
the latter two *require* at least *some* non-portable code.

Let's say for instance that on a particular platform, that an
"unsigned int" contains padding bits (or whatever they call those bits
that don't part-take in indicating what the number is). This could
possibly throw a big spanner in the works for playing around with
bitmaps.

However, it's still not impossible to achieve what you want if you
play around with arrays of "unsigned char". Indeed, the code might be
ugly, but it's definitely possible. And probably fun to write too.

Martin

[Malcolm McLean]

"Kelsey Bjarnason" <kb********@gmail.comwrote in message
news:nn************@spanky.localhost.net...

On Sun, 02 Sep 2007 12:54:23 +0000, Richard Heathfield wrote:

>Malcolm McLean said:

>>>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:6e******************************@bt.com.. .

Indeed. Everyone makes mistakes. To err is human, and all that.
People are not criticised here for making mistakes, but they *are*
(rightly) criticised for refusing to acknowledge them or to learn
from them.

It would be nice if that were true.

I think it *is* true, by and large. Mistakes *are* pointed out, and
rightly so, but to point out a mistake is *not* the same as to
criticise the person who made it. I make my fair share of mistakes (or
perhaps more!), but when people in clc point this out, I don't feel
threatened or intimidated by the fact. On the contrary, I welcome
corrections for what they really are - opportunities to learn and to
improve my programming.

Yeah, you just tend to make your mistakes so esoteric only about three
people are qualified to find them, let alone figure out the right way. :)

Harald van Dijk found one, I found another, so can you find a third?

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

[Malcolm McLean]

"Martin Wells" <wa****@eircom.netwrote in message
news:11**********************@r29g2000hsg.googlegr oups.com...

Malcolm:

>What are those ints going to be used for? We don't know, but such a
useful
function would surely find a place in calculating array indices, or
intermediate values, such as counts, to calculating array indices.

So we need another version

void AddFiveToEachElementsz(size_t *p, size_t len)

The fuse has gone off. That's what the admission of size_t does to your
code.

Sorry I haven't a clue what you're talking about. Could you please
explain more clearly?

Yes.
It the standards problem. As long as every nut will fit every bolt,
everything is simple. Engineer one says "give me a nut", engineer two
supplies it.

Once you allow for more than one standard, there is always trouble.
Engineer one says "give me a quarter inch nut". Engineer two "I can't, I've
only got a nut-making machine that does centimetres". Engineer one, "oh
never mind, I just need to fiddle with this design to make the holes
centimetres rather than quarter inch. Hardly matters. Back to you tomorrow".

sizes and counts are extremely common. Integers that don't ultimately end up
being used in index calculations are maybe a bit rarer, but not so uncommon
either. The function, as supplied, is positively inviting someone to use an
int for an index or size value, if for some reason he needs to add five to
every one of an array of indexes or sizes. We can fix that, by providing a
version that takes size_ts. But now we've just doubled the amount of code in
our system. If it turns out there is some error in the logic, can we
guarantee that both functions will be kept in synch? Maybe in some super, on
the ball, formal methods for eveything shop, but not in any place I've ever
worked.

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

[santosh]

Malcolm McLean wrote:

>
"Kelsey Bjarnason" <kb********@gmail.comwrote in message
news:cl************@spanky.localhost.net...

>On Sat, 01 Sep 2007 20:16:43 +0100, Malcolm McLean wrote:

>>No, limited experience, Not the same thing as incompetence at all.

>>If you write say, mainly code to drive GUIs under Windows, you will find
>that there's little point making much portable. Everything has to be
ripped
up and rewritten whenever the denizens of Redmond decide to realease a
new compiler anyway.

He said incompetence, and you just demonstrated it.

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. However the GUI to allow the user to enter these
numbers, check them, specify which columns to add up, and format the
report might be very non-trivial. So in fact the portable bit of the code
is a sum() function and maybe a few histogram or pie chart generators,
without the graphical part.

You can always write your own wrappers for platform specific GUI
functionality. Things like Java's Swing and wxWidgets prove that it can be
done. Of course it still won't be as portable as C code using only Standard
facilities, *and* it's likely to be a lot of work, but it's possible.

[Ian Collins]

CBFalconer wrote:

Ian Collins wrote:

>Mark McIntyre wrote:

>>Ian Collins <ia******@hotmail.comwrote:

#include <stddef.h>

extern size_t read( void*, size_t );

int main(void) {
char buf[10];
size_t n = read( buf, 10 );
return 0;
}

Standard C or not standard C?
Undefined - for all we know, read could do the following

So to be "standard C", every function has to be in the same file?

Not at all. But the source has to be available, and in std. C.

Isn't that where this whole silly debate falls down? If I were to write
a 100K line application in "standard C" and then add a 20 line file in a
library to give me access a serial port, you are saying the program
isn't standard C. While at the same time, people advocate putting
system dependent code in a library, so the wheel goes round...

--
Ian Collins.

[Peter J. Holzer]

On 2007-09-02 20:04, Ian Collins <ia******@hotmail.comwrote:

CBFalconer wrote:

>Ian Collins wrote:

>>Mark McIntyre wrote:
Ian Collins <ia******@hotmail.comwrote:

#include <stddef.h>
>
extern size_t read( void*, size_t );
>
int main(void) {
char buf[10];
size_t n = read( buf, 10 );
return 0;
}
>
Standard C or not standard C?

The translation unit is standard C. The program as a whole may or may
not be standard C, depending on how read is defined.

>>>Undefined - for all we know, read could do the following
So to be "standard C", every function has to be in the same file?

Not at all. But the source has to be available, and in std. C.

Isn't that where this whole silly debate falls down? If I were to write
a 100K line application in "standard C" and then add a 20 line file in a
library to give me access a serial port, you are saying the program
isn't standard C.

He's right, but is that important? Since 20 lines of your program aren't
standard C, your program won't run on every C implementation. It
may still run on a wide variety of systems, and be portable with little
effort to others (after all, there are only 20 lines to change). There
may be platforms to which it cannot be ported (because they have no
serial port and just doesn't make sense to use some other communication
medium instead).

While at the same time, people advocate putting system dependent code
in a library, so the wheel goes round...

Isn't that the same argument? You put the system dependent code in a
library to get a clean distinction between "standard C code" and "system
dependent code". When porting to a different system, you only need to
port the library, and all programs using the library will work on the
new system.

hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

[Martin Wells]

Malcolm:

Once you allow for more than one standard, there is always trouble.
Engineer one says "give me a quarter inch nut". Engineer two "I can't, I've
only got a nut-making machine that does centimetres". Engineer one, "oh
never mind, I just need to fiddle with this design to make the holes
centimetres rather than quarter inch. Hardly matters. Back to you tomorrow".

If I want to store a number, I use "unsigned". If the number can be
bigger than 65535, I use "long unsigned".

If the number can be negative, I use "int". If it can be outside the
bounds of -32767 to 32767, I use "long int".

That's pretty much it. No need to go delving through a Microsoft
manual, or a Linux manual, or an 8086 manual.

sizes and counts are extremely common. Integers that don't ultimately end up
being used in index calculations are maybe a bit rarer, but not so uncommon
either.

Unsigned integers are the default for me. I only use signed integers
when I want to be able to store negative numbers. "Int syndrome" is to
blame for the prevalence of signed integer types.

The function, as supplied, is positively inviting someone to use an
int for an index or size value, if for some reason he needs to add five to
every one of an array of indexes or sizes.

No, it's not. It's inviting the programmer to supply the function with
a positive number (even 0) indicating how many elements to modify. If
the type of the argument supplied is anything other than "size_t",
then a conversion takes place. If the programmer doesn't know how C
handles conversions, then they should either:

a) Consult a reference guide
or
b) Start drinking

Consistently, the people who are against size_t are putting across the
"incompetence" argument. Don't bitch at the author of the function
just because you missed the day in playschool where they talked about
unsigned integers.

We can fix that, by providing a
version that takes size_ts. But now we've just doubled the amount of code in
our system.

HAVEN'T GOT A CLUE WHAT YOU'RE TALKING ABOUT.

One function is all we need, whose parameter is a size_t. If you use
int instead, then you're a crap programmer, you're shit, you're
incompetant, and you don't know what you're doing.

If it turns out there is some error in the logic, can we
guarantee that both functions will be kept in synch? Maybe in some super, on
the ball, formal methods for eveything shop, but not in any place I've ever
worked.

No we can't guarantee they'll be in sync, especially since one of them
shouldn't even exist.

Martin

[Flash Gordon]

Malcolm McLean wrote, On 02/09/07 20:35:

>
"Martin Wells" <wa****@eircom.netwrote in message
news:11**********************@r29g2000hsg.googlegr oups.com...

>Malcolm:

>>What are those ints going to be used for? We don't know, but such a
useful
function would surely find a place in calculating array indices, or
intermediate values, such as counts, to calculating array indices.

So we need another version

void AddFiveToEachElementsz(size_t *p, size_t len)

The fuse has gone off. That's what the admission of size_t does to your
code.

Sorry I haven't a clue what you're talking about. Could you please
explain more clearly?

Yes.
It the standards problem. As long as every nut will fit every bolt,
everything is simple. Engineer one says "give me a nut", engineer two
supplies it.

Once you allow for more than one standard, there is always trouble.
Engineer one says "give me a quarter inch nut". Engineer two "I can't,
I've only got a nut-making machine that does centimetres". Engineer one,
"oh never mind, I just need to fiddle with this design to make the holes
centimetres rather than quarter inch. Hardly matters. Back to you
tomorrow".

As discussed last time you used this analogy. Nuts come in multiple
sizes. So if anything it is an argument for having multiple types for
multiple purposes rather than a single type for all purposes. BTW, some
nuts are not hexagonal, for example wing nuts.

sizes and counts are extremely common.

Yes.

Integers that don't ultimately
end up being used in index calculations are maybe a bit rarer,

Or maybe more common. This has not been established.

but not
so uncommon either. The function, as supplied, is positively inviting
someone to use an int for an index or size value, if for some reason he
needs to add five to every one of an array of indexes or sizes.

A very contrived example. Most of my integer code has been doing things
you would not want to do to sizes or counts. Most of what I have wanted
to do to sizes and counts has been too simple and obvious to want to use
a function.

We can
fix that, by providing a version that takes size_ts. But now we've just
doubled the amount of code in our system. If it turns out there is some
error in the logic, can we guarantee that both functions will be kept in
synch? Maybe in some super, on the ball, formal methods for eveything
shop, but not in any place I've ever worked.

As pointed out, you have the same problem if you want to use the
function with double, float, short or char or any other type.

If you want a language that allows you to avoid it try C++ where you can
use templates.
--
Flash Gordon

[Ed Jensen]

Mark McIntyre <ma**********@spamcop.netwrote:

>>There are very few regulars here in comp.lang.c that'll admit that
writing 100% portable C code is non-trivial.

So what? Writing portable C code /is/ straightforward. If you can be
bothered.

I would like to start this response with an apology.

With the exception of Martin, and now Mark, everyone has been very
reasonable in admitting that writing 100% portable C code is
difficult. My apologies.

However I suspect you're being just as religious as those you're
attacking, and this isn't about being right, is it?

I would like to see C evolve to better meet the needs of the modern
developer. I think the first step in that process is to recognize
some of the weaknesses of C.

[ian-news]

On Sep 3, 8:49 am, "Peter J. Holzer" <[e-mail]:

On 2007-09-02 20:04, Ian Collins <[e-mail]:

While at the same time, people advocate putting system dependent code
in a library, so the wheel goes round...

Isn't that the same argument? You put the system dependent code in a
library to get a clean distinction between "standard C code" and "system
dependent code". When porting to a different system, you only need to
port the library, and all programs using the library will work on the
new system.

Yes, but they appear to be arguing that once you call your system
dependent library, your program is no longer standard C. Catch 22.

Ian.

[Joe Wright]

Ed Jensen wrote:

Mark McIntyre <ma**********@spamcop.netwrote:

>>There are very few regulars here in comp.lang.c that'll admit that
writing 100% portable C code is non-trivial.

So what? Writing portable C code /is/ straightforward. If you can be
bothered.

I would like to start this response with an apology.

With the exception of Martin, and now Mark, everyone has been very
reasonable in admitting that writing 100% portable C code is
difficult. My apologies.

>However I suspect you're being just as religious as those you're
attacking, and this isn't about being right, is it?

I would like to see C evolve to better meet the needs of the modern
developer. I think the first step in that process is to recognize
some of the weaknesses of C.

You're in the wrong group. We don't want to make C better here. We want
to take the C we've got and help each other write better programs with it.

Changes to the language are better discussed in comp.std.c I think.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Keith Thompson]

ia******@hotmail.com writes:

On Sep 3, 8:49 am, "Peter J. Holzer" <[e-mail]:

>On 2007-09-02 20:04, Ian Collins <[e-mail]:

While at the same time, people advocate putting system dependent code
in a library, so the wheel goes round...

Isn't that the same argument? You put the system dependent code in a
library to get a clean distinction between "standard C code" and "system
dependent code". When porting to a different system, you only need to
port the library, and all programs using the library will work on the
new system.

Yes, but they appear to be arguing that once you call your system
dependent library, your program is no longer standard C. Catch 22.

It's not *entirely* standard C if it uses non-standard features.

If the program were entirely standard C, then you could recompile the
source on any other conforming implementation and expect it to work.
Few large programs are like that.

But there's nothing wrong with that. Not all programs *have* to be
100% portable.

We just don't discuss the non-portable parts here, that's 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]

Joe Wright <jo********@comcast.netwrote:

You're in the wrong group. We don't want to make C better here. We want
to take the C we've got and help each other write better programs with it.

For some limited definition of "we", perhaps.

[Mark McIntyre]

On Sun, 02 Sep 2007 22:26:05 +1200, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:

>Mark McIntyre wrote:

>>
Undefined - for all we know, read could do the following

So to be "standard C", every function has to be in the same file?

To be guaranteed standard, every function has to be either from the
Standard library, or visible to the programmer so they can verify it
is standard.

>To quote someone you might know "or they practice good progamming(sic)
technique and isolate interface code into different (and replaceable)
libraries".

Nongermane.
--
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]

On Mon, 03 Sep 2007 08:04:23 +1200, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:

>CBFalconer wrote:

>Not at all. But the source has to be available, and in std. C.

Isn't that where this whole silly debate falls down?

Nope.

>If I were to write
a 100K line application in "standard C" and then add a 20 line file in a
library to give me access a serial port, you are saying the program
isn't standard C.

Correct. The programme as a whole isn't standard C, since it relies on
features not standardised.

>While at the same time, people advocate putting
system dependent code in a library, so the wheel goes round...

The two points are not contradictory, they're complementary.
I'm surprised you can't understand these simple concepts.
--
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]

On Sun, 02 Sep 2007 22:45:57 +1200, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:

>Harald van Dijk wrote:

>No, but every function not provided by the standard library has to be
defined by the program.

Quite. The function read would be in a library.

Sorry but being contained in a library is *not* "defined in the
program".
--
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

[Joe Wright]

Ed Jensen wrote:

Joe Wright <jo********@comcast.netwrote:

>You're in the wrong group. We don't want to make C better here. We want
to take the C we've got and help each other write better programs with it.

For some limited definition of "we", perhaps.

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.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[CBFalconer]

Ian Collins wrote:

CBFalconer wrote:

>Ian Collins wrote:

..... snip ...

>>>
So to be "standard C", every function has to be in the same file?

Not at all. But the source has to be available, and in std. C.

Isn't that where this whole silly debate falls down? If I were
to write a 100K line application in "standard C" and then add a
20 line file in a library to give me access a serial port, you
are saying the program isn't standard C. While at the same time,
people advocate putting system dependent code in a library, so
the wheel goes round...

What do you want for nothing? The overall program is
non-standard. Porting elsewhere requires rewriting the portion in
the external file. The library doesn't affect the issue. Somehow,
in your example, I suspect that rewriting a defined 20 line file is
easier than rewriting a 100k application.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Malcolm McLean wrote:

>

.... snip ...

>
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. However the GUI to allow
the user to enter these numbers, check them, specify which columns
to add up, and format the report might be very non-trivial. So in
fact the portable bit of the code is a sum() function and maybe a
few histogram or pie chart generators, without the graphical part.

Apparently you never write anything computationally complex.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Richard Heathfield]

Joe Wright said:

Ed Jensen wrote:

>Joe Wright <jo********@comcast.netwrote:

>>You're in the wrong group. We don't want to make C better here. We
want to take the C we've got and help each other write better
programs with it.

For some limited definition of "we", perhaps.

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.

You are by no means the only one. There is a separate newsgroup for
discussing proposed language changes - comp.std.c - and those who want
to make C better can discuss it in that group.

If I may restate your claim with very slightly different emphasis:

"You're in the wrong group. We don't want to make C better *here*. We
want to take the C we've got and help each other write better programs
with it."

That doesn't mean we don't want to make C better. It just means that we
don't want to make C better *here*. We are perfectly happy to make it
better over in comp.std.c.

And for the record, in this reply "we" means "at the very least, Joe
Wright and myself, and quite probably a fair few others as well".

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

>Chris:

>Furthermore, the easy-ness of portability varies with the goal of
the code. Clearly, something like "calculate mortgage payments"
or "concatenate files specified by argv[] elements" is going to be
easier than "write an operating system" or "do bitmapped graphics":
the latter two *require* at least *some* non-portable code.

In article <11**********************@57g2000hsv.googlegroups. com>,
Martin Wells <wa****@eircom.netwrote:

>Let's say for instance that on a particular platform, that an
"unsigned int" contains padding bits (or whatever they call those bits
that don't part-take in indicating what the number is). This could
possibly throw a big spanner in the works for playing around with
bitmaps.

However, it's still not impossible to achieve what you want if you
play around with arrays of "unsigned char". Indeed, the code might be
ugly, but it's definitely possible. And probably fun to write too.

Indeed; and this would be completely portable, up to -- but not
including -- the step where you draw the results on your fancy
bitmapped color display. :-)

Often we (by "we" I mean "I and other people I work with") make
deliberate trades of "giving up some degree of portability for some
degree of performance". Continuing with the above example, we
might work with "unsigned int"s to handle 16 or 32 or 64 bits at
a time (however many are in "unsigned int") instead of restricting
ourselves to "unsigned char". I think it is important to be aware
that one is making such a trade-off, though.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Chris Dollin]

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.

--
(A.B)* OOPS Hedgehog
"It took a very long time, much longer than the most generous estimates."
- James White, /Sector General/

[jacob navia]

Ed Jensen wrote:

Joe Wright <jo********@comcast.netwrote:

>You're in the wrong group. We don't want to make C better here. We want
to take the C we've got and help each other write better programs with it.

For some limited definition of "we", perhaps.

YES.

I DO NOT BELONG TO THAT TRAFFIC POLICE!

[Richard Bos]

"Malcolm McLean" <re*******@btinternet.comwrote:

"Martin Wells" <wa****@eircom.netwrote in message
news:11**********************@r29g2000hsg.googlegr oups.com...

Malcolm:

The fuse has gone off. That's what the admission of size_t does to your
code.

Sorry I haven't a clue what you're talking about. Could you please
explain more clearly?

Yes.
It the standards problem. As long as every nut will fit every bolt,
everything is simple. Engineer one says "give me a nut", engineer two
supplies it.

Once you allow for more than one standard, there is always trouble.
Engineer one says "give me a quarter inch nut". Engineer two "I can't, I've
only got a nut-making machine that does centimetres". Engineer one, "oh
never mind, I just need to fiddle with this design to make the holes
centimetres rather than quarter inch. Hardly matters. Back to you tomorrow".

And your solution to this problem is to use oil tanker-sized nuts on
office chairs, or office chair-sized nuts on oil tankers. Frankly, I
think you're nuts.

Richard

[jacob navia]

Richard Bos wrote:

"Malcolm McLean" <re*******@btinternet.comwrote:

>"Martin Wells" <wa****@eircom.netwrote in message
news:11**********************@r29g2000hsg.googleg roups.com...

>>Malcolm:

The fuse has gone off. That's what the admission of size_t does to your
code.
Sorry I haven't a clue what you're talking about. Could you please
explain more clearly?

Yes.
It the standards problem. As long as every nut will fit every bolt,
everything is simple. Engineer one says "give me a nut", engineer two
supplies it.

Once you allow for more than one standard, there is always trouble.
Engineer one says "give me a quarter inch nut". Engineer two "I can't, I've
only got a nut-making machine that does centimetres". Engineer one, "oh
never mind, I just need to fiddle with this design to make the holes
centimetres rather than quarter inch. Hardly matters. Back to you tomorrow".

And your solution to this problem is to use oil tanker-sized nuts on
office chairs, or office chair-sized nuts on oil tankers. Frankly, I
think you're nuts.

Richard

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.

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.

[Martin Wells]

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.

The C Standard says that "int" and "unsigned" will be the "natural"
integer types, the quickest ones.

If the Standard Library functions didn't use "char" for strings then
I'd probably use arrays of int or unsigned. That's of course assuming
that I'm not low on memory.

The beauty of the C Standard when it comes to integer types is that
not only are they portable, but they turn out as efficient as possible
on the next platform too.

Only if you need a really big number or a really small negative
number, should you resort to anything bigger than "int" or "unsigned".

Only if memory consumption is a big deal should you resort to anything
smaller.

Of course, there's a few exceptions, like using char to play around
with bytes, or short to play around with small chunks of bytes.

Martin

[Richard]

Martin Wells <wa****@eircom.netwrites:

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.

The C Standard says that "int" and "unsigned" will be the "natural"
integer types, the quickest ones.

Efficiency isn't all about "quickest". Most people dont give a fig if it
takes 11 minutes to 10.5 minutes.

What is endemic though is this complete disregard for optimal data
sizes. It's called bloatware. It's part of the reason Machines are about
1000 times faster than in 1990 yet take the same time bring up a word
processor.

>
If the Standard Library functions didn't use "char" for strings then
I'd probably use arrays of int or unsigned. That's of course assuming
that I'm not low on memory.

C programmer should nearly always consider memory use IMO. It's one of
the things which gives C the edge.

I would be horrified if some idiot saved a million records to memory
using a size_t to represent the length in bytes of the records string
UID or somesuch.

Common sense.

[Richard]

Martin Wells <wa****@eircom.netwrites:

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.

The C Standard says that "int" and "unsigned" will be the "natural"
integer types, the quickest ones.

Efficiency isn't all about "quickest". Most people dont give a fig if it
takes 11 minutes to 10.5 minutes.

What is endemic though is this complete disregard for optimal data
sizes. It's called bloatware. It's part of the reason Machines are about
1000 times faster than in 1990 yet take the same time bring up a word
processor.

>
If the Standard Library functions didn't use "char" for strings then
I'd probably use arrays of int or unsigned. That's of course assuming
that I'm not low on memory.

The beauty of the C Standard when it comes to integer types is that
not only are they portable, but they turn out as efficient as possible
on the next platform too.

Only if you need a really big number or a really small negative
number, should you resort to anything bigger than "int" or "unsigned".

Only if memory consumption is a big deal should you resort to anything
smaller.

C programmer should nearly always consider memory use IMO. It's one of
the things which gives C the edge.

I would be horrified if some idiot saved a million records to memory
using a size_t to represent the length in bytes of the records string
UID or somesuch.

Common sense.

[Richard]

Martin Wells <wa****@eircom.netwrites:

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.

The C Standard says that "int" and "unsigned" will be the "natural"
integer types, the quickest ones.

Efficiency isn't all about "quickest". Most people dont give a fig if it
takes 11 minutes to 10.5 minutes.

What is endemic though is this complete disregard for optimal data
sizes. It's called bloatware. It's part of the reason Machines are about
1000 times faster than in 1990 yet take the same time bring up a word
processor.

>
If the Standard Library functions didn't use "char" for strings then
I'd probably use arrays of int or unsigned. That's of course assuming
that I'm not low on memory.

C programmers should nearly always consider memory use IMO. It's one of
the things which gives C the edge.

I would be horrified if some idiot saved a million records to memory
using a size_t to represent the length in bytes of the records string
UID or somesuch.

Common sense.

[Richard]

Richard <rg****@gmail.comwrites:

I would be horrified if some idiot saved a million records to memory
using a size_t to represent the length in bytes of the records string
UID or somesuch.

Common sense.

Hmm. Sorry about the double post. (Oh and I probably didnt mean a
million there - but you get the point).

[Chris Dollin]

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.

--
Chris "somebody stop me" Dollin

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

[jacob navia]

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.

It *could* be that disk caches go to 80MB and then it would be the same.
Not with main memory though. Main memory caches go into the MB range at
most, and L1 caches are even smaller.

Besides there are other effects to take into consideration.
Normally, machines load data from memory into a cache line
of 32 or 64 bytes, i.e. you read 32 bytes at a time.

Using sparingly memory, for instance making
your structure fit into 32 bytes, will make it load in a single
read operation into the L1 cache. Bigger structures take MUCH more
time since 2 or more reads are necessary...

The general point I want to make is that we have to use the correct type
for the data and situation we are working with.

It would be a bad situation where we would have just
"int with 64 bits"
and we would use int for characters, shorts, etc etc, wasting
an enormous space for nothing at each structure we would use.

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!

[Richard]

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

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.

Never let real world pollute the nirvana of c.l.c

If its not compilable on a DeepThought Nippon 0.2sxxyy Hiroshima
vibrator circuit then it's crap C. Never forget that.