PLEX86  x86- Virtual Machine (VM) Program
 CVS  |  Mailing List  |  Download  |  Newsgroups

Thou shalt have no other gods before the ANSI C standard 1657


Your Ad Here

Your Ad Here

Thou shalt have no other gods before the ANSI C standard 1661
David Wagner We aren't talking about reading and writing the whole mess. We are talking about indexing the mess to obtain an element. Then...

David Wagner

I won't argue this because it appears obvious to me that the arguments in favor of a particular size and against architectural sizes are repeats of arguments I heard 12 years ago about 32-bits and 22 years ago about 20 bits (ia16 address space).

But I will offer some data points. In 1982 I bought a computer for my personal use with as much capacity as was reasonably affordable. I did the same thing in 1992 and 2002. In 2012 I expect to buy another machine that is inconceivable prior to 2008.

1982 1992 2002 2012 ----------------------------- Disk(Gb) 0.020 2* 462 5-20e4 RAM(Mb) 0.064 64 3072 1-4e6**

Thou shalt have no other gods before the ANSI C standard 1658
Change the numbers in the above paragraph and it has happened before. Many times. So it turns out that somebody needs 100K more than 64- bit even, it's not enough. Probably don't need 128...

*from memory; may be off a little ** yes, I reasonably expect to have more RAM than disk given the trends.

Note that that is room for a lot of data. The Library of Congress used to be the largest single repository of information anywhere. It has about 20 Tb. That's nothing these days. And in the near future I expect GUIs to have it all in main memory, probably as an accessory similar to the early Borland TSRs..

Is there a 64-bit "crisis" looming? No. Do I expect one? No. Does that mean it's OK? Certainly not. If you write code correctly the language guarantees that you will never have a problem. Why should anybody ever accept any less?

Rephrase: "I know it's OK to use gets() to fill this buffer because the data rate of the incoming data means it will take longer than the average uptime() of the system for the buffer to overflow." It is simply nonsense and everyone (including the proponents I suspect) knows it.

What's worse is that these trivial distractions have nothing to do with the real issues of sloppy coding producing vulnerable software. Viz. both sides in this instance are aware enough of the issue that which ever side one is on one is unlikely to have a memory management problem in the near term (say 3-5 years).

Thou shalt have no other gods before the ANSI C standard 1660
David Wagner rate, Of course you are right in a limited way -- but you should...

So the whole debate is a waste of time. It's like brace placement. What ever you do do the same thing everywhere. And if you don't know what style to pick, then use the clbuttic style rather than inventing a new one.

tj3



Your Ad Here

List | Previous | Next

Thou shalt have no other gods before the ANSI C standard 1658

Alt Folklore Computers from Newsgroups

The #1 Usenet Provider on the Internet

Thou shalt have no other gods before the ANSI C standard 1656