size_t problems

[Kelsey Bjarnason]

[snips]

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]

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

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

[/QUOTE]

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

 

[Richard Heathfield]

Ed Jensen said:

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.

 

[Kelsey Bjarnason]

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.

 

[Kelsey Bjarnason]

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

 

[Kelsey Bjarnason]

[snips]

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.

 

[jacob navia]

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

 

[jacob navia]

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[/QUOTE]

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

 

[Ed Jensen]

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.

 

[Richard Heathfield]

Richard Tobin said:

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.[/QUOTE]

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.

 

[jacob navia]

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.

 

[Richard Heathfield]

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.

 

[Rob Kendrick]

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.

 

[Richard Heathfield]

Ed Jensen said:

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.

 

[Chris Torek]

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.

 

[jacob navia]

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.

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

jacob

 

[Ian Collins]

jacob:



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




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

 

[Rob Kendrick]

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.

 

[Malcolm McLean]

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.