«

On Mon, 25 Feb 2008 17:52:09 -0500, CBFalconer wrote:

> Kelsey Bjarnason wrote:
>> CBFalconer wrote:
>>> mike3 wrote:
>>>>
>>>> Busy-waiting is a known anti-pattern that should be avoided. However,
>>>> in C, there is no standard alternative, so when a wait is required
>>>> and it's not busy, the program becomes 100% non-portable. So then why
>>>> not include this type of non-busy wait functionality in the standard?
>>>
>>> Sure, just as soon as you describe to us a sure-fire positive method
>>> of so doing on all the types of systems on which C runs. Note the word
>>> 'all'.
>>
>> You have just eliminated the C standard library, at least significant
>> portions of it, as your "all" requirement there can't apply to them.
>> When will we be seeing the TC which eliminates all such functions from
>> the language?
>>
>> Or maybe, just maybe, that "all" notion of yours is just a tired old
>> red herring?
>
> 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.

Keith Thompson wrote:
> CBFalconer <> writes:
>
.... snip ...
>
>> Or, maybe, you should consider it as indicating the difficulty of
>> providing a portable generalized substitute for busy waiting?
>
> 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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



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

CBFalconer <> writes:
> Keith Thompson wrote:
>> CBFalconer <> writes:
>>
> ... snip ...
>>
>>> Or, maybe, you should consider it as indicating the difficulty of
>>> providing a portable generalized substitute for busy waiting?
>>
>> 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.

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.

--
Keith Thompson (The_Other_Keith) <kst->
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Mon, 25 Feb 2008 17:52:09 -0500, CBFalconer wrote:

> Kelsey Bjarnason wrote:
>> CBFalconer wrote:
>>> mike3 wrote:
>>>>
>>>> Busy-waiting is a known anti-pattern that should be avoided. However,
>>>> in C, there is no standard alternative, so when a wait is required
>>>> and it's not busy, the program becomes 100% non-portable. So then why
>>>> not include this type of non-busy wait functionality in the standard?
>>>
>>> Sure, just as soon as you describe to us a sure-fire positive method
>>> of so doing on all the types of systems on which C runs. Note the word
>>> 'all'.
>>
>> You have just eliminated the C standard library, at least significant
>> portions of it, as your "all" requirement there can't apply to them.
>> When will we be seeing the TC which eliminates all such functions from
>> the language?
>>
>> Or maybe, just maybe, that "all" notion of yours is just a tired old
>> red herring?
>
> 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.

Richard Heathfield wrote:
>
> Keith Thompson said:
>
> <snip>
>
> > Name one system with a hosted C implementation that doesn't have a
> > straightforward way of doing a non-busy wait.
>
> 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().



--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto

Kelsey Bjarnason wrote:
> CBFalconer wrote:
>
.... snip ...
>
>> 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.

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

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



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

On Wed, 27 Feb 2008 23:58:19 -0500, CBFalconer wrote:

> Kelsey Bjarnason wrote:
>> CBFalconer wrote:
>>
> ... snip ...
>>
>>> 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.
>
> 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.

Kelsey Bjarnason wrote:
>
> On Wed, 27 Feb 2008 23:58:19 -0500, CBFalconer wrote:
>
> > Kelsey Bjarnason wrote:

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

:-]

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto

[snips]

On Thu, 28 Feb 2008 14:49:14 -0500, Morris Dovey wrote:

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

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.