Storgae durations

[s0suk3]

(e-mail address removed) said:



Excuse me, but if they had *dis*agreed with my opinion, they *would* have
said so, at great volume. None of those I named is a shrinking violet. It
is quite likely that they won't bother to express disagreement with you
because you're not on their radar yet. But if you'd been *right*, you'd
have had big-gun support by now.

You can't say that they agree with you and not with me only because
they're your buddies and not mine. We'd have to hear it from them.

So have I, pretty much.

I meant objective in the sense that they were agreeing with neither of
us.

It seems that you have never heard of statistics or of probability theory.
We can use these tools to get very strong evidence indeed to support or to
attack a hypothesis such as yours.

Statistics would be indeed a strong evidence. Have we got any of those
yet?

For that to be true, most of the people developing new C programs would
need to be using C99 installations. Are you suggesting that all the C99
people are queueing to share a handful of C99 installations, whilst all
around them a vast desert of C90 installations remains practically unused?
I'm sorry, but I find that idea laughable.

Of course, people using C99 will have C99 installations. What I mean
is that there being more C90 or C99 installations is not the same as
most people using C90 or C99. For example, most C99 compilers are in
turn C90 compilers, but someone who has such a compiler isn't
necessarily using both C90 and C99.

Right. Similarly, there's no way to know the position and velocity of every
molecule of nitrogen, oxygen, etc, in an inflated balloon. Nevertheless,
we can make deductions about the behaviour of the balloon's contents,
because of statistically-based generalisations that prove to be remarkably
accurate - so accurate, in fact, that we often mis-name them as the "gas
laws". Statistics can be a very powerful science, even if it is
theoretically true that every molecule in the balloon could suddenly
"decide" to ram the balloon in the same place in a mad bid for freedom, in
practice this doesn't happen.

Right, but, as mentioned earlier, have we got any statistics yet?

Statistically speaking, absence of evidence of C99 is *not* evidence of
absence of C99, but it *is* evidence against C99's being the dominant
standard in the field, and it is sufficiently good evidence that you need
considerably more than "because I think so" to counter it.

You started the paragraph with the words "statistically speaking, ..."
What statistics are you basing on? You talk about absence of evidence
of C99, but you're forgetting about the absence of evidence of C90.
Also, I haven't said that what I say is true only "because I think
so."

On the contrary, anything that can work on three disparate embedded systems
is likely to be portable not only to Unix but also to Windows, Palm, Mac,
Amiga, and quite possible the big iron world too.

Sure, if there are compilers for those.

It's the definition used by every C programmer I know who uses the term
(except for you and Jacob Navia).

It isn't the definition used by every C programmer I know who uses the
term.

Then according to you Turbo C is a C99 implementation, and has been since
at least 1989, ten years before the 1999 Standard was published. What
prescience!

I presume it didn't have "minor" bugs and failures by that time,
though I'm not sure.

All the difference in the world. I agree with you about minor bugs, but if
there are known failures to implement the Standard, then either we ignore
them (in which case every C compiler is a C99 compiler), or we put our
foot down (in which case almost no C compiler is a C99 compiler).

Why? There are compilers that strictly conform to C99, though that
isn't so important. Anyway, no, they aren't so different. The only
difference is between knowing or not knowing about the failures. That
isn't a big difference.

You have not as yet persuaded me that you're able to do that. For example,
you seem unable to understand or give appropriate weight to a statistical
argument.

Isn't that the case for you, too?

Sebastian

 

[James Kuyper]

For it to be canonical, it would have to be widely accepted as such.
I've seen no sign of acceptance for the way you suggest, other than in
this discussion.

As I pointed out earlier, I reviewed a couple of hundred messages on
usenet containing the term "C99 implementation", and found many dozens
of uses of the term in ways that were inconsistent with the idea that it
includes nearly-conforming implementations. Though I did not keep count,
many different authors posted those messages, a lot more than the number
who have contributed to this discussion. I only found two authors who
used that phrase in a sense that required it to include
nearly-conforming implementations (and a lot of messages where it was
ambiguous whether or not newly-conforming implementations were allowed).

That pretty clearly establishes your usage, not ours, as the unusual one.

....

Have you really heard the opinion of *everyone* in the world who has
expressed an opinion? So far you've just talked about your opinion and
the one of the people in clc.

There's something called sampling - for a population that is too big to
be cost-effectively examined in detail, sampling is a perfectly
legitimate technique for collecting data that can be used to draw
conclusions about the statistical properties of that population, such as
the percentage of C Programmers familiar with the C99 standard who would
interpret "C99 implementation" in a given way.

In this discussion, we have three samples with strong biases (my own
experiences, Richard Heathfield's, and yours), and one much smaller
sample which was designed, as well as possible, to be unbiased. If this
were a more important issue, or if you had even bothered attempting to
collect an unbiased sample that turned out to support your
interpretation, I might want a larger sample size, and a better sampling
methodology. However, the samples we've collected so far seem sufficient
to support the conclusion that yours is a minority interpretation of the
term "C99 implementation".

....

Exactly. And that's exactly why we haven't been able to bring up any
strong evidence, and probably never will--at least not just by
discussing it.

No - if having a statistical universe of unknown size were something
that prevented one from reaching any conclusions about the
characteristics of that universe, then most of science would be
impossible. Statistics shows that it is the size of the sample, not the
size of the universe that it is a sample from, that determines the
accuracy of conclusions based upon that sample.

....

Well, perhaps, but there's no way to know which installations everyone
has.

There's also no way to know what height everyone has. However, that
doesn't prevent us from recognizing that a 16-foot tall person is
unusual, and not the norm. For the same reason, the lack of perfect
knowledge does not prevent us from using the knowledge we do have about
the implementations we've actually seen, to realize that installations
of compilers that fully conform to the C99 standard are quite rare.

By your definition of C99 implementation.

And mine, and that used by most of the authors I've read of messages on
either this newsgroup or comp.std.c, over a dozen years of posting to
those newsgroups.

Perhaps I misused the term. The dictionary defines it as

1. widespread; of wide extent or occurrence; in general use or
acceptance.

No one is using the term in any other sense here. The ratio of the
numbers of actual installations of each type of compiler is relevant
evidence concerning their relative prevalence. Drawing a conclusion
based upon such evidence, (particularly when the ratio is as large as it
actually appears to be), is far more reasonable than drawing a
conclusion inconsistent with that ratio, which is what you are doing.

 

[James Kuyper]

You can't say that they agree with you and not with me only because
they're your buddies and not mine. We'd have to hear it from them.

I think you've got it backwards; at least a few of the members of this
newsgroup could be counted on to race to disagree with him, if they
could, precisely because they are not his buddies. The silence of his
numerous enemies on this issue is a pretty strong indication that you're
alone in this.

....

I meant objective in the sense that they were agreeing with neither of
us.

Oh - so you have you're own private meaning for objective, too. What are
you going to call this new language of yours? I recommend against using
the term "English", because it can be confused with another popular
language.

Statistics would be indeed a strong evidence. Have we got any of those
yet?

The fact that you don't recognize that the evidence which has already
been provided constitutes a statistical sample is itself proof of your
lack of a knowledge of statistics.

Of course, people using C99 will have C99 installations. What I mean
is that there being more C90 or C99 installations is not the same as
most people using C90 or C99. For example, most C99 compilers are in
turn C90 compilers, but someone who has such a compiler isn't
necessarily using both C90 and C99.

No one has argued that they are the same, only that one is evidence for
the other. If a significant fraction of C90 installations were also
capable of conforming fully to the C99 standard, we would not be able to
determine from that fact whether they were being used in C90 mode or C99
mode. However, from the nearly complete absence of installations of
compilers that have a mode which conforms fully to C99, we can quite
reasonably conclude that development using such compilers in that mode
is quite uncommon.

....

Sure, if there are compilers for those.

You doubt that there are?

I presume it didn't have "minor" bugs and failures by that time,
though I'm not sure.

It certainly failed to implement C99, which was the thing you said was
was relevant. It implemented most of C99, pretty much the only features
of C99 that it failed to implement were those that were different from
the corresponding features of C90, which is pretty a small set.

 

[Richard]

I think you've got it backwards; at least a few of the members of this
newsgroup could be counted on to race to disagree with him, if they
could, precisely because they are not his buddies. The silence of his
numerous enemies on this issue is a pretty strong indication that
you're alone in this.

Enemies? There are no enemies. Only people that are sick to death of his
smarmy, godly, holier than thou persona and his egotistical preening. It
is more likely the "way" rather than the "what" that riles people with
him.

 

[James Kuyper]

....

Enemies? There are no enemies. Only people that are sick to death of his
smarmy, godly, holier than thou persona and his egotistical preening. It
is more likely the "way" rather than the "what" that riles people with
him.

It's really not relevant to my point what excuses they give for their
attitudes toward him; it's only the attitudes themselves that matter.

 

[David Thompson]

On Aug 18, 9:02 am, Richard Heathfield <[email protected]> wrote:

[about value of portable code]

It isn't possible to write anything that even nearly resembles a Web
browser in ISO C. A modern Web browser depends heavily on things like
Graphical User Interfaces, networking, threading, and OS environment
stuff. If 1% of the code did this things, what in heaven did the other
99%?

Things may be different for set-top boxes though I'm not sure. Certainly
graphics can be done in 100% ISO C if the OS allowed full privileges to
the program.

Graphics algorithms/(de)coding/rendering, yes. Actual display, no;
even if 'privilege' means writing directly to a display buffer and/or
engine, that part isn't standard. The semantics defined (portably) by
the standard only allow you to form addresses of, and access, declared
objects (aka variables) and space from malloc et al. The nonstandard
part may be only a few lines, leaving 99.9% standard, but not 100%.

Cooperative multitasking can be implemented in the place
of preemptive threading. Most of the networking too can be done in ISO
C except for the actual transfer which is simply an OS API call. The

Or preemptive can be localized into a small (nonstandard) module,
if not provided by the (also nonstandard) OS API.

meat of a web browser is of course the HTML parser and renderer, as
well code for HTTP, FTP, SSL, TLS etc. etc., all of which can be done
in ISO C except for the interface to the outside world, which is simply
an OS call or two. It won't be strictly conforming C, but it *can* be
highly portable C nevertheless.

I would add at least images (PNG, JPEG, more?) and perhaps other
mediatypes -- there is disagreement over whether those belong 'in' the
browser or as addons/plugins/etc., but for a settop-box in particular
I'd expect them to be important. And at least some scripting e.g.
Javascript. And CSS, although that's sort-of just HTML. And cache and
cookie management. SSL and TLS are within epsilon a single thing.
And perhaps Java, although doing that yourself rather than using Sun's
might not be worth it.

It's arguable whether 'the Web' should include FTP, and indeed whether
it should include graphics/media, but in practice it does.

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[dj3vande]

You can't say that they agree with you and not with me only because
they're your buddies and not mine.

That's not why he's saying they agree with him; he's saying they agree
with him because he knows that, had they disagreed, at least a few of
them would have said so.

We'd have to hear it from them.

For the record, then, I agree with Richard H.
(Though I don't think I belong on his list; because of priorities and
time constraints, I've become very aggressive with using the "Mark
thread as read" feature of my newsreader, so (especially for anything
that's being discussed in a long thread) I'm very likely to have not
seen any particular discussion and therefore not had any chance to
correct errors I see being made; he is correct, though, that had I seen
him making claims that contradict the reality that is observable in my
part of the world (and had others not already done so) I would have
informed him of the contradiction.)


A large part of my day job is split between new C development and
maintenance of existing C code, and I can say with confidence that
(a) none of the compilers that are in common use on any of the
platforms that we support or have talked about supporting support C99
or are likely to do so in the foreseeable future, and (b) even if that
were not the case, we would be unlikely to write any new code that
required C99 until *all* the platforms we might want to support have a
C99 compiler readily available, which at the current rate of adoption
seems unlikely to happen before the heat death of the universe.

For hobby projects, the set of (compiler,platform) combinations is
larger, and the same comments apply: No known current or likely C99
implementations, very small probability of one appearing, and
vanishingly small probability of enough appearing to make targeting
them worthwhile.


dave