Storgae durations

[Ben Bacarisse]

Keith Thompson said:

Well that is why I said I could, just, get the meaning you seem to
have taken from it, but the surrounding context seems be all the nearby
sentences, both before and after.

Precisely so.

Matter are not helped by the fact you split a sentence. Un-split
(which is the only fair way to read what someone writes) we have:

I don't know exactly which platforms are supported by C99
implementations, but let's name five (random) platforms for
illustration [followed by the list]. But ... something that
is portable among that much platforms is very portable.

You then remark that the OS/390 people might cough and splutter a bit
at that.

This is followed by a sentence (in the same paragraph) that raises
doubts about C99 even for this list. Thus of the four sentences only
one is, apparently, is not about C99 availability.

If OS/390 has a C99 compiler[1], I find it odd that you chose to
insert a comment on general portability by citing a system that does
not suffer from the particular portability problem being discussed.

Nevertheless, if someone as bright as Ben can misinterpret
it, I am beginning to wonder whether I was as clear as I should have been
in my original statement.

The balance (in the general case) is a tricky one. Spelling out every
single nuance of every thought is (a) too time-consuming, and (b)
insulting to my readership, and (c) probably impossible anyway. But my
more usual strategy of leaving people to make what *I* consider to be
obvious and trivial leaps of logic appears to run the risk of being
misunderstood even by bright people.

It never occurred to me, when I was writing a reply to Sebastian's
eyebrow-raising claim that we might paraphrase as "if it works on this
handful of tiny systems, well, that's portable enough for rock n' roll",
that my reply about parochialism might be taken as a claim about C99's
availability or otherwise on mainframe systems.

Sebastian's list was of platforms that (he thought) support C99
implementations which was clear both from the sentence you splint and
that fact that you immediately followed your OS/390 remark by raising
doubts about C99 support. That makes the context so strong that, for
me, clarity would require some sort of re-write.

To me, it reads like this:

S: You can make jelly from lots of fruit.
H: Jam can be made for far more fruit. If you want the widest choice
it has to be jam.
S: Well I don't know exactly what you can and can't make jelly from,
but lets name five (random) fruits for illustration: plums,
raspberries, red currents, black currents, apples. Something you
can make from that many fruit is very flexible.
H: I think the quince growers might splutter a bit if they heard
you say that. But since you don't actually know whether you can
make jelly from the fruit you name, your point lacks force.

Of course you don't say you can't make jelly from quinces, but it read
to me as an odd way to make a general remark about the flexibility of
fruit and special position quinces might (or might not) have.

I must have re-read it a dozen times now, and I still can't see how
it could be interpreted that way. Nevertheless, I recognise that Ben
isn't stupid, so I suppose there must be some way of looking at the
wording that completely changes the meaning.

I don't see it as "completely changing the meaning" to allow the
context from the previous and following sentences to be the reason for
the coughing and spluttering. "That's hardly a representative list of
systems" and "That's hardly a representative list of systems with C99"
are not that far in meaning and with C99 availability bracketing the
remark it is not unreasonable to assume it had some relevance.

Perhaps Ben could
explain how he arrives at that interpretation.

I hope I have shed some light on it. I have been able to see both
readings from the start (one reason I've stay out of the thread) but
one seemed to me so much more likely -- that OS/390 has no C99 and it
is that that would cause all the coughing and spluttering -- that I
was growing more and more perplexed. Of course, it does not help that
Jacon Navia's first response (in this sub-thread) attributed to you a
wild claim that you more certainly never made.

[1] This is still in question. I have seen no reference to a C99
compiler for OS/390 though I am too out of date with IBM letter soup
to know what significance many of the posts have. I would still like
to know if this legacy system has a C99 compiler, despite that having
(it seems) not bearing on this matter. Presumably, Richard, you know
if there is one.

 

[Ben Bacarisse]

this is his definition of "very portable". Note he didn't say there
was a C99 implementation for them.

Actually he did (it has all got clipped and chopped) and Richard goes
on to call that claim (that they have C99) into question in his very
next sentence. Both Sebastian and Richard are talking about C99
availability both before and after the OS/390 remark. This, to me, is
the problem. I have posted elsewhere at more length about this.

I understand perfectly well (now) what was intended, but I think there
is more scope for interpretation than some people seem to suggest.

 

[Ben Bacarisse]

Yes, that's precisely how I read it. That required about as much
gymnastics as a stroll through the park. In English, the word 'that'
refers to the most recently mentioned thing that it could reasonably
be considered to apply to.

In this case, 'if they heard you say that' very clearly refers to the
last thing he said, which was "By what I'd call "common standards,"
something that is portable among that much platforms is very
portable." That statement that didn't say anything at all about C99,

But is was a statement about C99 availability. By now that fact has
got snipped and the context was further obscured by an another
inserted remark that broke the sentence but Richard certainly knew
this or he would not have continued: "But since you don't actually
know whether the platforms you name have C99 implementations available
for them, your point lacks force". A paragraph break here would have
helped, since then the remark about OS390 would stand on its own.

I am happy to accept the interpretation offered, but it seems to me
the less obvious one, simply because I requires one to drop the
context (C99 availability) and the take it up gain immediately.

It takes quite a bit of verbal gymnastics to misinterpret "to hear you
say that" as referring to anything other than the most recently made
comment. Possibly this is a way in which English differs significantly
from French?

No French involved -- English is my first language. If I
misunderstood then one can assume some other reasonably well-educated
English speakers might do likewise.

 

[jameskuyper]

I am happy to accept the interpretation offered, but it seems to me
the less obvious one, simply because I requires one to drop the
context (C99 availability) and the take it up gain immediately.

In my experience, general statements are often mixed in with more
specific ones, and comments on those more general ones that don't
limit themselves to the current context are a routine occurrence.
However, to be fair, I also remember a number of very confusing
discussions I've read or participated in which one person missed a
context switch that the other person took for granted.

No French involved -- English is my first language.

My apologies. I was pretty sure that we had someone from France
posting to this group, other than Jacob. I had mistakenly remembered
you as being that person . It made a certain amount of sense: two
French speakers, same mistaken interpretation. Now I'll have to
abandon that hypothesis. Your interpretation seems far less plausible
to me than what Richard actually intended, but I'll concede that it's
a possible one. I think that the right lesson to learn from this
discussion is that we need to be careful when using words like "he",
"it', or "that", to make sure that it's clear what they refer to.

 

[santosh]

Ben Bacarisse wrote:


My apologies. I was pretty sure that we had someone from France
posting to this group, other than Jacob.

That would be Charlie Gordon I suppose.

<snip>

 

[jameskuyper]

That would be Charlie Gordon I suppose.

No, the person I was thinking of had a family name that sounded at
least vaguely french to me. Gordon doesn't qualify, no matter how
French he may actually be - his name recalls Scotland to me, not
France. I just did a moderately exhaustive search, and I couldn't find
any regular poster other than Ben whose name was a good fit to my
memory. There's a good reason why I normally rely upon pen and paper,
or electronic storage media, rather than my own memory :-(.

 

[Jean-Marc Bourguet]

No, the person I was thinking of had a family name that sounded at
least vaguely french to me. Gordon doesn't qualify, no matter how
French he may actually be - his name recalls Scotland to me, not
France. I just did a moderately exhaustive search, and I couldn't find
any regular poster other than Ben whose name was a good fit to my
memory. There's a good reason why I normally rely upon pen and paper,
or electronic storage media, rather than my own memory :-(.

If you are looking for a french speaking Belgian living in France, I'm
here. But I'm far from a regular poster.

Yours,

 

[J. F. Lemaire]

If you are looking for a french speaking Belgian living in France, I'm
here. But I'm far from a regular poster.

Well, I'm a French speaking Canadian living in Belgium and I'm probably
even less of a regular poster

Cheers,
JFL

 

[Ben Bacarisse]

No, the person I was thinking of had a family name that sounded at
least vaguely french to me.

My name is French and I have spoken of it here due to the (slight)
irony that Jacob Navia has miss-spelt it more than once. May be you
filed this information as "Ben speaks/is French".

 

[jameskuyper]

Ben Bacarisse wrote:
....

My name is French and I have spoken of it here due to the (slight)
irony that Jacob Navia has miss-spelt it more than once. May be you
filed this information as "Ben speaks/is French".

Thanks! With that hint, I now remember that this is what happened. My
memory has always been somewhat unreliable, and is getting more so,
but it's not completely unreliable - yet.

 

[Antoninus Twink]

The proof is irrelevant, it's the incessant ranting that puts people's
backs up.

I think it only puts up the backs of people who've already decided to
join in Heathfield's puerile bullying campaign of Jacob.

Do you really believe that Mr "Heathfield"'s smug, smarmy,
self-satisfied arrogance, or Mr "Vip Star"'s semi-psychotic posts do
less to "put people's backs up"?

 

[s0suk3]

(e-mail address removed) said:


Yes and no.

See?

In the case in point, whether C99 is the "current" standard depends on what
we mean by "current".

Well, the dictionary says "passing in time; belonging to the time
actually passing." That's the way I meant it in this context too.

Implementors have ignored C99 in droves, and most
current implementations conform to C90 but not to C99. There is therefore
little point in holding up C99 as the "current" standard because it's...
well, I won't say it's unimplemented because that's clearly not the case -
but it's not so widely implemented that those who care about portability
can yet reasonably assume that all those who will be compiling their
software have a C99 implementation available.

I'd argue they can (and usually do) reasonably assume that.

Even on platforms where a
C99 implementation exist, a given customer may not be prepared to lay out
the necessary money to purchase a licence for that implementation.

That'd be the case too for an implementation of any standard.

Yes, I know.

<snip>





Not at all. I've been aware of that since April (or was it May?) 2000, when
Jack Klein posted an announcement of the fact in this very newsgroup.

Funny, because in your previous post you didn't seem to be aware of
it.

That's curious, since you don't use C99 yourself (or at least, that's the
impression I get from your previous articles on the subject).

You continue to (extremely) misinterpret the same things in the same
ways.

It also
suggests that you have a very, very limited experience of other C
programmers. I've been using C since 1989, and by far the overwhelming
majority of C programmers I've known personally and "met" on the Net use
implementations that conform to C90 but not to C99.

Perhaps most software nowadays is written in C90, because it's been
around for far more time and there are lots of apps that were written
before C99 joined the party. But what I meant is that people starting
to write new apps usually choose C99.

Only if we accept your apparently very limited experience as being typical,
which I certainly don't.






Ah, so I did. My mistake. I apologise for getting that wrong.


And that is a reasonable thing to do in, as you say, this context.



Well, that's not what the GNU folks say.

Well, I haven't peeked around the site to see if they say that, but
what I said was just from common sense, since you can compile C99
programs in it.

VLAs are broken, complex and
imaginary support is broken, and IEC 60559 support is broken. Therefore,
gcc is *close* to being a C99 compiler, but it isn't actually there yet.
Furthermore, glibc has a number of outstanding issues.





Then you're using something that isn't gcc. It's curious that you mentioned
gcc, then.

No, I _am_ using GCC.

Nor do you see the word "imperfect". The Standard does not give explicit
permission for implementations to be imperfect.

Since it mentions neither of the words "perfect" nor "imperfect," I'm
afraid the terms are outside the scope of the standard, and are
therefore subject to each of our very personal interpretations of
them.

If it doesn't conform perfectly, it's non-conforming.

I wasn't using the term "perfect" as in "perfect conformance," but as
in "perfect implementation," the latter being, as mentioned above,
subject to each of our definitions for those terms.

[...] I
think I shouldn't have to mention any further that your standards of
portability are radically different from mine.

That's true. My standard of portability is very simple but (necessarily)
very demanding. Clearly, you're more relaxed about portability, which is
fine, as long as that relaxed attitude meets your needs, which presumably
it does.

[...] Your "proof",
so-called, says that you don't know what you're talking about and you
consider yourself free to re-define your terms as you go along,
therefore you must be right.

No. The fact that my standards for something are different from yours
doesn't mean I'm re-defining anything.

But it proves you wrong.

For a proof to prove anything, it has to be convincing. Yours is not.

I thought it was convincing.

Those who program in the common subset of C90 and C99, of course.


It's far more relevant than you seem to realise. Whilst it is certainly
true that many programs require features that are not available in ISO C
and whose models and interfaces differ from platform to platform, it is
also true that a great deal of almost any program can be written portably,

Not if it's anything other than the typical main() program that prints
some stuff and then returns 0;

and the portable parts carefully separated from the non-portable parts so
that only the non-portable part need be written for each new platform. My
favourite example is a Web browser product for set-top boxes that was
already well-established when I joined the project, and which comprised
about half a million lines of code, of which 99% (495,000 lines or so) was
written in ISO C - and yes, it was C90, not C99, although C99 had been the
de jure standard for at least a couple of years by then.

Well, in two years, I doubt there were any implementations for more
than just a couple of platforms. But Time's Changed.

Every time they
needed to add support for a new platform - which seemed to happen two or
three times a year - they only needed to rewrite around 5000 lines of
code, which took about a month each time. I don't think it's possible to
write a decent modern Web browser in ISO C - but I *do* think it's
possible to write 99% of a decent modern Web browser in ISO C, because
I've seen it done.

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

Guess what I'm going to say next - no peeking, now...

No, they don't.

Guess what! They do.

No, I don't think we are.




In what way, then?

Well, unlike you, I don't have the fantastic and unrealistic luxury of
limiting an app to ISO C. And since I need to use platform-specific
functionality, I always know what my app is going to be ported to, and
I need to write different implementations to use the same
functionality on each of the platforms the code's ported to.

Counter-example: If you write a program that uses C99-conforming VLAs,
initially for compilation by a truly C99-conforming compiler, you run the
risk that your code won't port to gcc, because gcc's VLAs don't conform
fully to C99.

Well, not to GCC, but like I said, to any conforming implementation
(or to any that implements enough).

(BTW, how are GCC's VLAs "broken"? Why do they work?)

No, I'm not concerned with extensions in this discussion. I'm concerned
with the problems inherent in porting code that assumes a conforming C99
implementation is available, to a platform where there isn't such an
implementation (either because no such implementation exists or because it
hasn't been obtained by the organisation in question).

Like I've been repeating, I don't see how that's a problem, since
there are enough platforms on which there are C99 implementations
available.

It's an illustration. I use those a lot. The purpose is to assist in
communicating my meaning, in cases where there seems to be some
misunderstanding. I suspect that you are being somewhat disingenuous.




C89 mentions "nonconforming" once, in non-normative text. C99 mentions
"nonconforming" once (again in non-normative text) and "non-conforming"
twice, in each case referring not to the implementation but to the
program. Either an implementation conforms, or it isn't a C
implementation. There is no such thing as a non-conforming C
implementation because, unless it's a conforming implementation, it isn't
a C implementation.

Since the standard uses it to refer to the program but not to the
implementation, then that's yet another term that's outside of the
scope of the standard.

Then it's a C90 implementation, but not a C99 implementation.

Guess what! It's both a C90 and a C99 implementation.

That was the whole point of the example. Compilers can't always tell
whether a function will be used incorrectly at the point where they are
compiling that function. By the time they are compiling the call, they
might not be able to see the function that is being called (because it's
in a different translation unit). It is therefore unreasonable to place
limitations on implementations with regard to undefined behaviour.

/My/ whole point was what happened if the function invoked undefined
behavior by itself; i.e., independently of the way it was called,
since that way it *is* obvious to the compiler that the code invokes
undefined behavior.

...which contains no undefined behaviour whatsoever.


Observe the requirements of the Standard - i.e. do whatever it likes.


From a conformance point of view, yes, sure. From a QoI point of view,
that's a matter for the customers to decide.






&i doesn't evaluate the indeterminately-valued i, so that's fine, and the
assignment to p is fine. Incrementing p points to "one past" i, which is
(just) fine, as long as the pointer isn't dereferenced, which it isn't.



Yes, that's absolutely true. And if the implementation of choice is known
to wipe the disk if it encounters such behaviour (strange implementation
to choose, but hey, you know what managers can be like), then developers
will get a lot of practice in reinstalling operating systems - and, as a
side effect, will learn to be more careful in future.

I think avoiding that inconvenience would be worthier than a
programming lesson.

One of my measures of productivity is the amount of code I *don't* have to
rewrite when my code has to work on a new platform.

....and for that, it will be more than helpful to have the best
possible set of tools available.

Well, I do understand that point of view, and mostly (on the UB issue, not
the C99 issue) I guess I'm just arguing for the sake of arguing. Whilst I
would find a pathological implementation fun to use, I wouldn't want it to
be installed on my principal development machine!

Sebastian

 

[Antoninus Twink]

(e-mail address removed) said:

Yes and no.

[reams and reams of similar nonsense snipped]

Heathfield is the master of subterfuge and equivocation. Trying to argue
against his word games is a complete waste of time and energy, and will
only provoke a deep frustration that obviously brings Heathfield a
perverse sense of satisfaction.

When even the placid Ben Becarisse accuses Heathfield of deliberately
laying a trap for Jacob in this thread, can there be any doubt of his
bad faith and dishonesty?

 

[Antoninus Twink]

He DID NOT SAY OS390 (z/VM) DID NOT HAVE A CONFORMING C99 COMPILER.

Of course not. Heathfield doesn't deal in plain statements, but in word
games, smoke and mirrors. He very very clearly *implied* that S390
doesn't have a conforming C99 compiler, but as with any illusionist he
allowed himself enough wiggle room to pull back and claim he said
something with no meaning instead.

 

[Antoninus Twink]

I begin to wonder whether the french equivalents to 'lie' and 'false claim'
are the same word? IOW whether in french there's no distiction between a
deliberate wrong claim and an accidental one?

In this case, Heathfield's wrong claim was certainly deliberate. As a
native English speaker, I call that a LIE.

 

[s0suk3]

(e-mail address removed) said:



Fine. Then C90 is the current Standard, because it's the one people
actually program against, *now* - well, most people, anyway.

We've yet got to see if that's true, or if it's the contrary.

Relatively
few have even heard of C99,

Sure, if they live in the past. Nowadays, it's the contrary.

let alone use C99-conforming implementations -
especially since there is this growing trend for people to use free
software if they can, and (as far as I'm aware) there isn't yet a single
free C99-conforming implementation.

I don't know much about compilers, but even I have heard about Intel.

[C99 is] not so widely implemented that those who
care about portability can yet reasonably assume that all those who will
be compiling their software have a C99 implementation available.

I'd argue they can (and usually do) reasonably assume that.

Then you and I live on different planets.

Something like that...

Right - but everybody and his dog has a C90-conforming implementation, and
of course there are plenty of free C90 implementations.

So is the case for C99.

Well, so far the only implementation you've mentioned using is gcc, which
doesn't conform to C99.

That's not what I was denying.

Given that most people starting to write new apps don't actually have a C99
implementation,
False.

it's hard to imagine how your remark could possibly be
true.




Yes, *if* they are carefully written not to make use of C99 features that
gcc doesn't implement in a conforming way. But if that's an acceptable
working definition of "C99 implementation", then Turbo C 2.01 is a C99
implementation! The definition is uselessly broad.




Ah, I see. I thought you mentioned using a C99 implementation, but it seems
you're using gcc instead.

Same misinterpretations, over and over again.

A perfect implementation would conform perfectly. Thus, if it fails to
conform perfectly, it fails to be a perfect implementation.

Like I said, that's your very personal opinion, not universally
applicable.

[...] Your "proof",
so-called, says that you don't know what you're talking about and you
consider yourself free to re-define your terms as you go along,
therefore you must be right.
No. The fact that my standards for something are different from yours
doesn't mean I'm re-defining anything.
Sorry, but it doesn't convince me.
But it proves you wrong.
For a proof to prove anything, it has to be convincing. Yours is not.

I thought it was convincing.

Yes. Many "provers" think their "proofs" are convincing. But proofs have to
convince **other people**. Your "proofs" certainly don't convince me.

"Proofs" are usually rejected by the person being proved against.

Not only do I refuse to dismiss filters &c as easily as you do, since they
can be very important and useful programs, but also I disagree with your
main point. It is possible, however, that you missed the vital words "a
great deal of".



In fact, I don't think there were any C99 implementations at the time.


Not significantly. There are still hardly any C99 implementations, and we
still don't have C99 conformance from some significantly big guns such as
Microsoft or GNU.

Microsoft and GNU aren't the only vendors. Anyway, what you mention is
generally not so important, since GNU supports C99, even though it
doesn't conform.

I agree. It is, however, possible to write 99% of it in ISO C.


You take the non-portable stuff, and wrap it up in an abstraction layer.
That is, you enclose the non-portable functionality in functions with a
common interface. Then, whenever you need to do graphics or networking or
threading or whatever it is, you call not the native routines but the
abstraction layer routines, the "wrappers"... It's not as easy as it
sounds, and it requires a certain amount of discipline, but it /is/
possible.

That's exactly what I do. However, how does that make 99% of the code
ISO C? All the implementations for each of the platforms is precisely
what takes big amounts of code. And the code that uses those common
interfaces is not exactly ISO C anymore, according to clc'ers.

It's hardly a luxury. Quite the reverse, in fact. But mostly I ship
libraries and filters, not "applications" in the sense of big GUI
explore-my-features programs. When I do get the opportunity to write
"applications", I consider it a luxury. It's certainly a lot of fun.

Well, I was talking about "luxury" in the sense that, given C's broad
portability, the app will be portable to a whole lot of platforms.

Ah, now *that* is what I would call a luxury, and it's utterly unrealistic
from my perspective - but clearly not from yours.


That sounds very unproductive. Still, whatever floats your boat. Yes,
/some/ rewriting will be necessary where the application makes even
relatively light use of the platform's features, but careful modularity
can reduce this task to a relatively insignificant proportion of the total
development time.

Actually, what I was describing is exactly what you described above
about the common interfaces and abstraction layers. And it is very
cool that you can wrap up all that platform-specific functionality
into a single interface, but still, the implementation for that
interface on each of the platforms isn't always fun :-( At least it
isn't as fun as having ISO C do all the work for you, as it does with
files.

According to GNU: "Some details of variable length arrays (VLAs) relating
to when size expressions are evaluated and when the memory for VLAs is
freed are not implemented, and other details are not checked against the
requirements of the C99 standard."






If I write a C99-conforming program *now*, and email it to you, I can't
guarantee that it will execute correctly on your system, because I can't
guarantee that you have a C99 implementation. You claim to have one, but
the only implementation you've mentioned is gcc, which isn't
C99-conforming. Because I can't guarantee that you have a C99-conforming
implementation, I can't use C99 if I want to guarantee that my program
will work on your system. The same applies to the vast majority of my
users - I suppose /some/ of them will have C99 implementations, but I'm
not actually aware of any.

But I'm not one of your users, and if I were, I would have already
told you my about my system and what I can accept from you and what
not, so your analogy does not apply.

Guess what! [gcc is] both a C90 and a C99 implementation.

Well, it may well *become* a C99 implementation, but it has not done so
yet.

Oh it already did...

Sebastian

 

[s0suk3]

(e-mail address removed) said:





It is not in dispute that C90 *was* the Standard against which people
programmed (because this was certainly the case before C99 existed). It is
you who claim that things have changed - that most people now use C99. The
burden of proof is therefore on you. (Saying "it's so" does not constitute
proof.)

That's clearly something nearly impossible to prove. And I didn't say
"it's so," I said "We've yet got to see if that's true, or if it's the
contrary," which isn't even an affirmation.

Whether things change or not is not a possibility, though; it's a
fact: if time passes, things change. There's for example the
(diminutive) possibility that C99 was the most widely used standard in
the minute it was available, but I think something like that would be
impossible to prove. So the point is that it's just as impossible to
prove that C99 is more widely used than C90 as it is impossible to
prove the opposite.

Again, the burden of proof is on you, since it is you who are making the
claim that things have changed.



Perhaps you'd be so kind as to point out where Intel claim C99 conformance.

At their site:

http://softwarecommunity.intel.com/articles/eng/2635.htm

They don't conform? We should send them a note!

Perhaps you'd be so kind as to provide some URLs.

Whenever you're so kind as to provide URLs that prove that everybody
and his dog has a C90-conforming implementation.

It's not clear what you're denying (other than reality, of course).

You said

"That's curious, since you don't use C99 yourself"

which I denied. Then you said

"Well, so far the only implementation you've mentioned using is gcc,
which doesn't conform to C99."

which is not the same thing, and therefore is not what I denied.

If you are so confident that I'm wrong, you should have no difficulty in
demonstrating this. Please feel free to try.

Neither did you demonstrate that you were right. (And there's no way
to do that.)

No misinterpretation. If you are using gcc, you are *not* using a
conforming C99 implementation. If you are using something else, fine, but
I'm not a mind-reader.

When have I claimed that I'm using a conforming C99 implementation by
using GCC?

This is the real world, not a seminar on postmodernism. Either an
implementation conforms or it doesn't. It isn't a matter of opinion.

Once again: saying "an implementation conforms, but it doesn't" is a
null statement, and I've never said anything like that, and it's not
what I meant when I said that it was your personal opinion.

If acceptance of the proof is a matter of opinion, it's not really a proof,
is it?

You yourself said: "For a proof to prove anything, it has to be
convincing." That suggests that it's a matter of opinion, since,
according to the dictionary, "convincing" means: "appearing worthy of
belief." So if someone believes it, it's that person's opinion that
it's true.

Sure, but their implementations are used by a very significant proportion
of the C programming community. I've cut a lot of C code for a lot of
companies over the years, on a fair number of platforms - but when I've
been writing C on the PC, I have invariably used either Microsoft C, gcc,
or Borland C. Every company for which I ever wrote PC-based code (and a
few that I turned down, and a few that turned me down) used one of those
three implementations. I never came across a company that used any other
implementation for PC-based code. And none of those three implementations
is C99-conforming.


It may not be important to *you*, but it's important to people who need to
know that their code will work on multiple implementations.

Limiting the code to a subset of the language won't reduce
portability.

<snip>





+---------------------------------------------------+
| |
| |
| A p p l i c a t i o n |
| |
| L o g i c |
| |
| (lots, in ISO C) |
| |
| |
+---------------------------------------------------+
| A b s t r a c t i o n L a y e r (thin) |
+---------------------------------------------------+
| Non-portable code, rewritten for each platform |
+---------------------------------------------------+


In which case you're not abstracting it enough.




There's more than one kind of luxury. But yes, it's nice when you can take
a program from /here/, move it to that different platform over /there/,
and have it work right out of the box.




Very true.


How kind. Most of them don't bother. They just assume that I'll send them
stuff that will work on their system.


It isn't an analogy. It's how I do stuff in the real world. Because I
cannot rely on my users having C99, I can't use C99 (except the bits of it
that are also C90, of course).

Hilarious. If they don't tell you anything about their system, how can
you know they even have a C90 implementation? That makes the whole
point null.

<snip>
Guess what! [gcc is] both a C90 and a C99 implementation.
Well, it may well *become* a C99 implementation, but it has not done so
yet.

Oh it already did...

Not according to GNU. Forgive me, but I think they have a better idea of
whether their product conforms than you do.

Like I've said, I only say it's a C99 implementation because you can
compile C99 programs in it and because it supports most of C99 (i.e.,
it's common sense). Have they actually said, "we don't have a C99
implementation"? If so, could you point me to the site where it's
stated?

Sebastian

 

[Keith Thompson]

Like I've said, I only say it's a C99 implementation because you can
compile C99 programs in it and because it supports most of C99 (i.e.,
it's common sense).

A pure C90 implementation with no extensions also supports most of
C99.

Have they actually said, "we don't have a C99
implementation"? If so, could you point me to the site where it's
stated?

It's implied by <http://gcc.gnu.org/c99status.html>, unless you insist
on referring to implementation that doesn't fully conform to the C99
standard as a "C99 implementation".

 

[s0suk3]

(e-mail address removed) writes:

[...]

Like I've said, I only say it's a C99 implementation because you can
compile C99 programs in it and because it supports most of C99 (i.e.,
it's common sense).

A pure C90 implementation with no extensions also supports most of
C99.

Technically, yes. But this isn't the case of most compilers that claim
to support C99, such as GCC, where you normally don't even note the
failures, unless you go see the website.

I was also talking about usability. Clearly a compiler that would
claim to support C99 by only implementing the subset that corresponds
to C90 wouldn't be as useful as one that actually tries to implement
most C99 features (if you're using C99).

It's implied by <http://gcc.gnu.org/c99status.html>,

The site marks the features and failures of C99 in GCC. Where does say
that they don't have a C99 implementation? The most relevant part I
found regarding this subject is

"This page describes the C99 support in mainline GCC, not in any
particular release."

unless you insist
on referring to implementation that doesn't fully conform to the C99
standard as a "C99 implementation".

That's precisely what I've been saying.

Sebastian

 

[santosh]

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