Why not provide a standard non-busy waiting method?

[Kelsey Bjarnason]

Or, maybe, you should consider it as indicating the difficulty of
providing a portable generalized substitute for busy waiting?

I just find it amusing to watch someone assert that something must apply
to "all types of systems on which C runs" while apparently being
completely unaware of the fact that entire swaths of the C standard
*already* fail to meet this criterion.

 

[CBFalconer]

.... snip ...


Name one system with a hosted C implementation that doesn't have a
straightforward way of doing a non-busy wait. POSIX systems have
sleep(); other systems, I'm sure, have something similar.

CP/M. Try comp.arch.embedded too.

 

[Keith Thompson]

CP/M. Try comp.arch.embedded too.

comp.arch.embedded is largely irrelevant, since I was talking about
hosted implementations. (I'm assuming that a freestanding C
implementation implies an embedded system and vice versa; this
assumption might not be 100% accurate.)

Ok, so there are a few old systems on which implementing a
sleep()-like might be difficult. But if were added to the standard,
surely it would have a mechanism for indicating failure, just as
time() does.

I think we're both repeating ourselves, so we probably might as well
let this drop.

 

[Kelsey Bjarnason]

Or, maybe, you should consider it as indicating the difficulty of
providing a portable generalized substitute for busy waiting?

So, have you gotten around to explaining, yet, why it's okay to include
largish portions of the standard library which cannot be implemented on
many systems, yet it's not okay to include _this_, which might be
problematic on a few?

Or is this just another case where consistency need not apply?

I'm all for being consistent, of course. We'll start by gutting much of
stdio and see what's left of the language when we're done.

 

[Morris Dovey]

Keith Thompson said:



MS-DOS (unless you count TSRs, which should almost certainly count as
cheating).

CP/M, as provided by Digital Research.

A great many CP/M users wrote their own BIOS. Mine included
context switching and an equivalent to sched_yield().

 

[CBFalconer]

CBFalconer wrote:
.... snip ...


So, have you gotten around to explaining, yet, why it's okay to
include largish portions of the standard library which cannot be
implemented on many systems, yet it's not okay to include _this_,
which might be problematic on a few?

Or is this just another case where consistency need not apply?

I'm all for being consistent, of course. We'll start by gutting
much of stdio and see what's left of the language when we're done.

What portion of the standard library do you consider
unimplementable on many systems?

 

[Kelsey Bjarnason]

What portion of the standard library do you consider unimplementable on
many systems?

Me? Not sure. Some folks, however, seem to think there's a problem, so
they created this weird little notion of a "freestanding implementation",
one which isn't required to support largish portions of the standard
library, apparently due to some weird view that, oh, fopen and its kin
aren't really implementable on a Coke machine or an ABS control system.
You know, systems where C can run.

Hence the comment: if "all" is the byword, why are these systems given an
"out"? Last I checked, they qualified as part of "all". So do we remove
the nonsense about freestanding implementations, under the argument that
a function must be implementable by _all_ systems capable of running C
(and thus making freestanding implementations irrelevant; they either
_can_ support every function, or they cannot run C), or do we scrap the
notion of "all", admitting that some things really aren't supportable on
all systems capable of running C? If the latter, the argument provided
against the non-busy-wait fails. Or do we scrap the bits of the standard
which aren't implementable?

Which functions, though? Hmm. Good question. Can a C program be
implemented on a ROM? If so, we might have to eliminate memset, memcpy,
strcpy, strcat and the like, as these won't - can't - function as
expected. Hard to to a memset when the memory you're trying to write is
read-only.

Just a start. I'm sure a little clever thinking will find many more
functions which cannot be implemented on *all* systems capable of running
C.

 

[Morris Dovey]

Me? Not sure. Some folks, however, seem to think there's a problem, so
they created this weird little notion of a "freestanding implementation",
one which isn't required to support largish portions of the standard
library, apparently due to some weird view that, oh, fopen and its kin
aren't really implementable on a Coke machine or an ABS control system.
You know, systems where C can run.

My sarcasm detector winked at me, then went dark - so I'm not
quite sure how to interpret your comment. I guess I'll respond by
saying that the folks who wrote the standard made a serious
attempt to maximize reasonableness and minimize all tendancies to
allow their geekishness to wax pathological.

Hence the comment: if "all" is the byword, why are these systems given an
"out"? Last I checked, they qualified as part of "all". So do we remove
the nonsense about freestanding implementations, under the argument that
a function must be implementable by _all_ systems capable of running C
(and thus making freestanding implementations irrelevant; they either
_can_ support every function, or they cannot run C), or do we scrap the
notion of "all", admitting that some things really aren't supportable on
all systems capable of running C? If the latter, the argument provided
against the non-busy-wait fails. Or do we scrap the bits of the standard
which aren't implementable?

Neither. What we do is to lean back in our chair and consider the
bad old days when we wrote embedded code in assembly languages,
then we nod in Brian and Dennis' general direction, and we take
pleasure in having a tool that allows us to be satisfyingly
productive in a wide variety of hardware environments.

I've always preferred to write/draw with a sharp pencil - but
somewhen (it might've been about the time I was learning to
write) I discovered that if I put too fine a point on the lead,
the tip would break off as soon as it was applied to paper. By
third grade I'd learned how fine the point could be so as not to
break at first use.

It's almost painful to watch you attempt to oversharpen this
tool...

Which functions, though? Hmm. Good question. Can a C program be
implemented on a ROM? If so, we might have to eliminate memset, memcpy,
strcpy, strcat and the like, as these won't - can't - function as
expected. Hard to to a memset when the memory you're trying to write is
read-only.

You remind me of a skit that appeared regularly on an old TV
program called "Hee-Haw!" - a thououghly blond gal walks into a
doctor's office, raises her arm about halfway, and says: "Doctor,
Doctor, it hurts when I do this!" and the doctor invariably
replied: "Well, don't do that!" as he chased her out of his
office.

A psychiatrist might be more interested (than would be a
programmer) in hearing about _why_ you're determined to memset()
a read-only space...

Just a start. I'm sure a little clever thinking will find many more
functions which cannot be implemented on *all* systems capable of running
C.

Sir, please step away from the pencil sharpener...

:-]

 

[Kelsey Bjarnason]

[snips]

Sir, please step away from the pencil sharpener...

Cute, but misdirected.

The proper direction of that missive should be towards the folks who, on
one hand assert that for something to be worthy of consideration as part
of C, it must be implementable on "all systems capable of running C",
while at the same time apparently being unaware that C *already* fails to
meet this criterion.

It's like that old Monty Python skit...

And what have they ever given us in return?

The aqueduct?

What?

The aqueduct.

Oh, yeah, they gave us that, that's true.

And the sanitation!

Oh, yes, and sanitation...

....


All right ... all right ... but apart from better sanitation and medicine
and education and irrigation and public health and roads and a freshwater
system and baths and public order ... what HAVE the Romans ever done for
US?


Same sort of deal here. What does it take to qualify for inclusion in C?

It must be implementable on every system capable of running C.

But what of freestanding implementations?

Oh, yes, okay, it must be implementable on every system capable of
running C, or must be removable when it cannot be so implemented.

It is high comedy at its finest, to be sure, but it does not make a
particularly compelling argument to exclude any given feature based upon
whether it can be implemented on all systems capable of running C or not.