usage of size_t

[spinoza1111]

Not really. C isn't a language that lends itself to proper exception
support because there are too many points where exceptions fall flat.
One can see the problems by looking at C++. C++ exceptions are useful
to a point, but in my opinion they're not nearly as beneficial as they
would be if C++ integrated them more fully into the language (throwing
an exception on out of bounds array indexing, for example) and had
native garbage collection.

By the time you plug the holes, you'll have something more like Java
or C#.

Which some brilliant people at Sun and Microsoft have done. Moore's
Law should take care of the rest. Why is C not given a hero's funeral?

No, you didn't make it clear at all. The statement I quoted and
replied to can easily be interpreted as: copying to a linked list
makes the system run slow if there's 'just enough' memory. This
suggests that referencing in a linked list wouldn't run slow in the
same situation, which is the implication that my reply refutes.

Well, anything slows down if there's just enough memory. But I don't
understand you, and I don't think you understand me. So, I shall
repeat myself: Richard's solution does in many scenarios an
unnecessarily large malloc for struct elements, and then it does an
unnecessary copy. It betrays incomprehension of linked lists. If he'd
started out as I started out on second generation equipment (an 8K
1401 in my case) he'd have a better appreciation of storage
complexity. It seems that for him, memory is free.

I agree that copying large objects may be problematic, especially with

It IS.

an extra malloc call. I don't agree that it's a deal breaker. I'm not
the only one who's suggested that copying a pointer to the data rather
than the data itself is one way to get the effect of referencing with
a copying linked list. You just need to be aware of your memory
management (as one should be), and avoid unnecessary copies on the
client side.

One irritating characteristic of some of your replies is the sudden
entry of terminology such as "client side" which doesn't necessarily
apply in the abstract problem. My "client", if you mean dear Richard's
caller, is sending me data from The Great Beyond. Both me and Dickie
Wad need to have a meaningful address during the duration of the call
(I need it for a picosecond to set a four or eight byte thingie-poo to
point to the data: he needs it for an unpredictable amount of time),
so this is a given.

My assumption is that the address of the data will be stable. OK,
suppose in real scientific asceticism that I should Occam this
exception's balls off, and throw it out, just as I threw out string.h
elsethread.

Then yes, I must copy.

However, this means that on my computer, I should not trust addresses
ever to be stable at all, and should always, in brief intervals of
stability, copy things.

This defeats the whole purpose of a Von Neumann machine.

Copying should be an option in an extended linked list processor. As
the only way, it's absurd.

See above.



The copy may be an extra cost. Or it may not. Let's say the original
object being copied is a local variable as opposed to dynamically
allocated memory. A copy is necessary if the list node lives longer
than the scope of said local variable. Either way you're calling
malloc and copying the object.

Makes no sense. If the element is a local variable, there's almost no
reason (I can think of) to make a copy for posterity!

The data items x1,x2,...xn, let us say, are all developed as local
variables for shits and giggles inside a procedure. The procedure
makes a linked list of those values using Dickie Wad's code.

This linked list is either itself declared as a local variable as
x1,x2...xn at the same level of static nesting or it is not.

If it is, then when they go out of scope, so does the linked list. Uh,
Dickie, why did you make a list? You had the variables, chump.

If it is not, then outside the scope, those variables have NO meaning,
unless you've decided to preserve them for use elsescope. But why did
you need a linked list to do this? OK, you wanted to make a copy of a
bunch for use elsescope. So why didn't you use an ARRAY in the first
place?

There are situations where it makes sense to put data in a linked
list. But there are MORE situations in which you don't want to make a
copy.

Richard's design is actually very close to the boilerplate for my own
published container libraries atwww.eternallyconfuzzled.com(which
may or may not be designed differently if I rewrote them). The
container maintains 'dup' and 'rel' delegates which manage copying and
releasing of the contained objects. When creating a new node, dup
copies the data as in:

node->data = container->dup(data);

When deleting an existing node, the pointer is released:

container->rel(node->data);

If one wants copying semantics, simply call malloc and copy the data
in dup, then free it in rel. For referencing semantics, return the
argument in dup and do nothing in rel:

void *dup(void *data)
{
  return data;

}

void rel(void *data)
{
  // No work needed

}

This design is preference agnostic in that copying and referencing are
both supported. However, if I were writing about data structures, I'd
only mention this design in passing (or attach complete libraries as
supplementary to the chapter) because the extra fluff takes away from
the topic being taught.

You don't do yourself justice. Elegance, said Dijkstra, such as yours,
is in computing science a matter of life and death. Galileo said it is
the frills, the extras that add "nobility and excellence to a
scientific theory". Mies van der Rohe said God is in the details. The
post modern architect Venturi said, less is less.

Richard said d'oh, copy da data.

You may notice that I follow this pattern in my tutorials on that site
if you've read them. The tutorials typically use integer data and a
copying design to minimize boilerplate code and highlight the data
structures being described. Then the libraries act as supplementary to
exhibit a more reusable implementation.

Your work is probably light years ahead of Richard's, and wanna know
why? Because you write like a girl, which is a compliment. You're not
afraid of complex sentence structure and your orthography is perfect.
Whereas I've noticed in my thirty year career that male programmers
like Richard range from loudmouth braggarts like him, who while he
doesn't make elementary errors in writing, doesn't like the written
word and falls into shibboleth and saw to save his "valuable" time,
and little backstabbers like Seebach whose writing stays at the
shallow end of the kiddie pool, being creative only when he's
inventing new logical fallacies.

As Dijsktra said, great programmers can write well.

The only problem, in fact, that I see in your texts is a corporate
vice: being even handed, overly interested in sacrificing first
principles to "trade offs", and giving equal time to evil.

 

[Julienne Walker]

Which some brilliant people at Sun and Microsoft have done. Moore's
Law should take care of the rest. Why is C not given a hero's funeral?

For the same reason COBOL hasn't: there's a great deal of existing
code out in the wild. In many cases, it makes no sense to upgrade
because there's little or no benefit to justify the time, cost, and
risk of rewriting working code in a different language simply because
the current language is outdated.

It IS.


One irritating characteristic of some of your replies is the sudden
entry of terminology such as "client side" which doesn't necessarily
apply in the abstract problem.

I'm making the distinction between a reusable library and code that
uses the library (the client). This distinction is important because
while a library will have consistent performance attributes, the
client can vary wildly. However, the two must work together to be of
any use. Without clients, a reusable library is pointless, and without
the library, the problem is no longer abstract. We would need to
consider the problem domain of a concrete application to make educated
decisions about performance.

The only problem, in fact, that I see in your texts is a corporate
vice: being even handed, overly interested in sacrificing first
principles to "trade offs", and giving equal time to evil.

I don't see being even handed as a vice. Impartially judging every
option and choosing the best among them produces the best results. If
you're biased, you can easily miss options or opportunities that may
be superior. Classifying things as "evil" is a fantastic way to close
doors on yourself.

 

[Seebs]

For the same reason COBOL hasn't: there's a great deal of existing
code out in the wild.

Not just that. There are problems where Moore's Law isn't enough, because
ANY improvement in speed is pretty worthwhile, and where native C tends
to win.

Kernels, for instance.

-s

 

[Ian Collins]

You are now on record as claiming that you know even less about C than
someone whom you don't even recognise as a programmer, and no amount of
deception will refute this.

Classic! I think I'll print that one for posterity. Thank you Richard.

 

[spinoza1111]

Yes, I know less about C than you, and you're no programmer, Richard.
That is the truth. You have memorized facts but you simply cannot code
properly, and your linked list proved it.

Don't feel too bad. Your buddy Seebach is even less of a programmer.
Many other people know details about the syntax and even semantics of
programming or natural languages but are not programmers of the one,
nor can function in the other. There were many college professors of
Chinese who were unable to travel to mainland China between 1949 and
1980 who could not at first function in Beijing or Shanghai Puthongua
after China opened after 1980, and their are no genuine speakers of
Latin, are there.

Furthermore, a programmer would be in my view able to learn object
oriented programming apart from rote anti-OO sloganeering, and you've
had twenty years to do so, and you haven't.

Bill Gates, who wasn't a programmer or at least not a very good one,
said it well nonetheless to Susan Lammers for "Programmers at Work" in
1986. He said he wanted developers who would, when confronted with the
need to learn a new programming language, take the manual home, read
it in the evening, and start work the next morning.

The only place one gets this ability is through university study (or
in exceptional cases autodidact study) of computer science independent
of instantiation in code, and your linked list folly proves you don't
have this.

Forest and trees. You're so full of shit about details that you cannot
think outside the box.

 

[spinoza1111]

Not just that.  There are problems where Moore's Law isn't enough, because
ANY improvement in speed is pretty worthwhile, and where native C tends
to win.

Kernels, for instance.

Perhaps, although C is by no means the only language in which to write
a "kernel".

But you're not qualified to infer from the fact that C MIGHT be the
best choice for a "kernel" to the silly idea that it's a good idea to
write C for silly little filters with bugs in them,

 

[spinoza1111]

For the same reason COBOL hasn't: there's a great deal of existing
code out in the wild. In many cases, it makes no sense to upgrade
because there's little or no benefit to justify the time, cost, and
risk of rewriting working code in a different language simply because
the current language is outdated.




I'm making the distinction between a reusable library and code that
uses the library (the client). This distinction is important because
while a library will have consistent performance attributes, the
client can vary wildly. However, the two must work together to be of
any use. Without clients, a reusable library is pointless, and without
the library, the problem is no longer abstract. We would need to
consider the problem domain of a concrete application to make educated
decisions about performance.

No, that's not the case here, and the view that there is an extra load
of "problem domains" over and above computer science, applied common
sense, the law, and compassion for others has created the software
crisis, in my view.

The problem is that there are no "first principles" of corporate
management. Peter Drucker thought he knew them for the same reason
Alan Greenspan thought he knew how to manage the economy, and both, at
the end of the day, admitted defeat.

This is why I think programmers should regard themselves, not as the
slave-servants of corporate executives, but as the assistants to
workers and the people.

Specifically, a programmer who's programming a machine tool should
regard the operator as his user; the programmer whose developing a
banking application should regard the teller and the customer on the
other side of the grille as his most important users. This will sound
strange to American programmers, but in fact, Ole Johan Dahl developed
object oriented code in Denmark in order to best document and build
the systems he developed for Danish workers, because in Danish law
such systems had to have input from labor unions.

The superstition that there is something magic about "requirements"
and that only a special priestly class of failed programmers, promoted
into "analysts", has created too much pressure on programming time as
the analyst's dried voices whisper amongst themselves about
"requirements". The "analysts" are corrupted by the power struggle
amongst executives for control.

I don't see being even handed as a vice. Impartially judging every
option and choosing the best among them produces the best results. If
you're biased, you can easily miss options or opportunities that may
be superior. Classifying things as "evil" is a fantastic way to close
doors on yourself.

New Age psychobabble, albeit literally expressed, of the sort used to
discipline people who in fact know what they are doing.

Look, despite the fact that I'm smarter than many people here, I have
a track record. I spoke the truth, and people don't like it, so I'm
"it". Being even-handed in my case just perpetuates an injustice, and
I need affirmative action at this point.

That may sound self-serving, and it is, for let us not speak falsely
now. The point is that no situation is a level playing field: to make
a level soccer field in my community here in China, which is a
mountainous island, the village elders had to pave a small area on the
waterfront, and I regularly see the kids banging their knees. The
"level playing field" is a fantasy of justice, to which people in the
US Midwest or at Harrow are addicted, since they have big football
fields in the former and green grassy swards in the other. In
Bangladesh, kids play "football" in the street using the street's
rules, and they know what's being done to them.

The time is past for a level playing field. I don't accept Richard's
solution save as an option.

 

[Mark L Pappin]

Neither did I. Hence the **s around "reasonably".

It's possible that BC has just blown his cover.

mlp

 

[Seebs]

Is that right? Does anyone want to run a sweepstake on how many libel
threats Mr Nilges will issue over the rest of this year?

That's apparently normal. The guy who was going on and on about how I was
a horrible Nazi on another forum kept saying he was going to contact my
employer, possibly our CTO, in order to ensure that I was revealed as a
fraud who simply didn't know about dynamic memory allocation. (This
because I claimed that VLAs were not an example of static storage.)

Never happened, which is a shame, because my boss was all ready to respond
with "you say he doesn't know C? what's C?"

-s

 

[spinoza1111]

That's apparently normal.  The guy who was going on and on about how I was
a horrible Nazi on another forum kept saying he was going to contact my

This is an instance of a new logical fallacy, argument from story,
which incorporates all the defects of argument from false analogy and
adds its own.

A valid argument from analogy is used properly in law. "My client,
like the accused in Snoid v Snoid, O'Herlihy v Bronstein, and the
Lady's Delight case, is a certifiable lunatic. In all of these cases,
the M'Naghten rule was applied. Therefore M'Naghten applies here.".

An invalid argument from analogy appears when significant features
differ, as in "the accused calls for M'Naghten to be applied because
he is a certifiable lunatic. However, the crime in question is not a
capital crime. Therefore, analogy does not apply."

But here, in this break-room Hooters horseshit, Peter repeats a story
about another poster who also called him a Nazi. The intent here can't
be to make even a false argument from analogy, since the issue in the
other forum isn't even mentioned, merely the accidental behavior of
the other poster.

In a false argument from analogy, a majority of the non-accidental
facts and laws correspond, only to have at least one fact or principle
fail to apply. But here, no principle is in common, only a couple of
accidental facts.

In the Seebach Fallacy, the purpose, shared by Fascist use of media,
is not to make an argument. It is to occupy media bandwidth with an
alternate story that it is hoped will occupy mental RAM in the public
mind, rather like The Protocols of the Elders of Zion or the film Der
Ewige Jude.

In fact, using the Seebach Fallacy easily backfires in many cases. If
another guy called Seebach a Nazi, that is in ordinary statistical
inference a data point. We can use "argument from valid authority" if
perchance this other guy, like me, has for shits and giggles read
Theodore Adorno's and Max Horkheimer's Dialectic of Enlightenment and
Hannah Arendt's The Origins of Totalitarianism to find that Fascists
use media in certain ways, for he's then a cite.

If he hasn't, we can still use statistical inference to start
wondering about Peter's behavior. However, we need to be careful to
avoid another logical fallacy Seebach makes, which he's defended as a
logical principle.

This is that he actually believes that he can, by himself, reason from
unusual behavior (which could be anything from objectively deviant
behavior to being more literate than Peter) to a conclusion about
abilities.

Peter believes that one and only one data point can be used to make an
inference here, whereas a more traditional reasoner would think,
"whoa, you mean in another discussion some fella was moved to call
Peter a Nazi and threaten a lawsuit? Doesn't this mean, based on the
fact that no conspiracy could exist between the mighty Nilges and this
other guy, that it's Peter whose the problem? And hey, maybe I should
get with that guy so we could afford better legal counsel in a
miniature class action!"

employer, possibly our CTO, in order to ensure that I was revealed as a
fraud who simply didn't know about dynamic memory allocation.  (This
because I claimed that VLAs were not an example of static storage.)

Never happened, which is a shame, because my boss was all ready to respond
with "you say he doesn't know C?  what's C?"

How nice for you. So here's another way to Succeed in Programming
Without Knowing Jack: work for a manager who doesn't know C.

If you want to succeed in coding without knowing Jack
If you want to step up and start makin' jack, Jack,
Here's your plan, my man, to make your smack Daddy attack:
First, takedown someone with a computer science education
Find twenty trivial typos in a popular programming book
And start cryin' ooooooh baby dis author is damnation.
Then pay your way onto the C standards board
Sit uncomprehending in meetings in which you gonna get bored
But that's okay, it ain't gay, because then you now is not some dope
You is "Peter Seebach who of C is closer 'n shit to the Pope".
Then get an easy job finding bugs and sending them to Bangalore
For a boss who don't know Jack about C and real C lore
You won't get any bootie, women gonna hate you cuz you's a loser
But you can come to Hong Kong and pay ... you gets to choose her!

 

[fj]

I almost never use a do-while.

Usually you need a empty case where the loop never executes. Other
times it's easier to code the logic into a while loop.
In Fortran 77 the fact that a loop body always executes at least once
can be a real nuisance..

Except that this strange behavior has been precisely REMOVED by the
arrival of FORTRAN-77 !

You are referring to a very old FORTRAN version called either
FORTRAN-66 or FORTRAN-IV.

 

[Nick Keighley]

Not really. C isn't a language that lends itself to proper exception
support because there are too many points where exceptions fall flat.

I'm surprised

One can see the problems by looking at C++. C++ exceptions are useful
to a point, but in my opinion they're not nearly as beneficial as they
would be if C++ integrated them more fully into the language (throwing
an exception on out of bounds array indexing, for example)

that might be nice, though it would be a rather different language

and had native garbage collection.

I don't see why garbage collection is necessary for exceptions to work
properly. I always thought RAII was one of C++'s nicer features. With
Java etal you are never really sure when the resource disappears.

By the time you plug the holes, you'll have something more like Java
or C#.

well only because you insisted on garbage collection...

<snip>

 

[Nick Keighley]

Julienne Walker wrote:
***
By the time you plug the holes, you'll have something more like Java
or C#.
***

Not just that.  There are problems where Moore's Law isn't enough, because
ANY improvement in speed is pretty worthwhile, and where native C tends
to win.

Kernels, for instance.

and garbage collectors

 

[Moi]

and garbage collectors

And algorithms and algorithm books.
In my observation, even Knuth writes demonstration programs in C, and Cweb.
C is a sort of portable (M)MIX.

HTH,
AvK

 

[spinoza1111]

Julienne Walker wrote:

***
By the time you plug the holes, you'll have something more like Java
or C#.
***




and garbage collectors

But this doesn't justify using C for much more. And based on my
experience in IBM, I'd guess that the C code is generated or highly
structured so as to be "quirky".

 

[Julienne Walker]

I'm surprised


that might be nice, though it would be a rather different language

Yes, that's the point. Not being able to use exceptions is only a pity
if C were in any way suitable for supporting exceptions. ;-)

I don't see why garbage collection is necessary for exceptions to work
properly. I always thought RAII was one of C++'s nicer features. With
Java etal you are never really sure when the resource disappears.

The problem with RAII is in handling errors on destruction. In C++ you
*do not* throw from a destructor to avoid the risk of throwing from a
destructor while a previously thrown exception is unwinding the stack.
If this happens, the default behavior kills the process with a call to
abort().

Garbage collection removes a large number of cases where you might use
RAII (as memory is the most common resource). The problem still
exists, but it's greatly minimized. That's why I included garbage
collection. In more general terms, more management by the language
(runtime) is needed for exceptions to be properly integrated, and if
they're not properly integrated, you have a half-assed solution.

well only because you insisted on garbage collection...

Garbage collection is actually a minor feature in this case. It isn't
strictly necessary, but when methods of finalization are considered
one feels pressed to manage memory as well. Otherwise you'll end up
with, using two common examples, a ton of "smart objects" under an
RAII method or far more finally blocks than many programmers would be
comfortable with in a try/catch/finally method.

 

[Richard Bos]

I have to take some exception to this, because Dr. Seuss was actually an
extremely skilled writer of English, even though many of his books don't
make this obvious to casual observation.

Certainly, but he wasn't a writer of English _for skilled readers_, at
least not in his more well-known work. He wrote for beginners - and did
so well. But one mustn't confuse his skill with that of his audience.

Richard

 

[Richard Bos]

^^^^^^^^^^^^^^^^


There were no 0xa0 (NBSP, non-breaking space) characters in Seebs's
post. It was in plain ascii. However, you have introduced many in
your reply, and I have replaced them in the quoted text with @ signs
so you can see them.

You appear to be using some software which replaces multiple spaces
(such as double spaces at the end of sentences) and tabs with
sequences of alternate NBSPs and plain space characters. I can only
conjecture what horrible environment this might make sense in.

It is one of the many ways in which Google Broken Beta caters to idiocy
and carelessness.

Richard

 

[Richard Bos]

If two pointers that point to the same thing don't compare equal,
then the implementation is non-conforming. C99 6.5.9p6:

IIRC the only way to get two such pointers was by pointer manipulation
that would be considered to have undefined behaviour in ISO C, BICBW.

Richard

 

[Tim Rentsch]

You are incorrect.

Its max value is *AT LEAST* 65535.

It may be much, much, much, larger.



I don't understand what you are trying to do.

Use size_t for sizes. If you are recording the number of items in a thing,
and it's zero or more, use size_t, that's what size_t is for. It doesn't
matter what the type is or whether or not it's 65535 bytes or more or
less. If you can have a buffer of over 65535 bytes, then size_t will be
able to represent sizes over 65535.

Certainly that seems to be the expectation, but I don't
think it's required or necessarily guaranteed. I'm
pretty sure a conforming implementation could have
SIZE_MAX == 65535 but still allow

char too_big[ 100000 ];

for example. And that's only one way of getting a buffer of
more than SIZE_MAX bytes.