Re: Storgae durations

s0suk3@xxxxxxxxx said:
Richard Heathfield wrote:
s0suk3@xxxxxxxxx said:
Richard Heathfield wrote:
s0suk3@xxxxxxxxx said:

<snip>


He said the
standard you referred to is no longer current.

Yes, he did, and yes, he's de jure right. But he's de facto wrong.

Either he's right (which he is), or he's not.

He's right only in a completely useless and almost meaningless way.


How can someone be right in a meaningless way?

It's not difficult, but someone can also be wrong in meaningless ways...

Again, either someone is right, or not. It's *that* simple.

....and that's a good example.

What do you mean by "de facto"?

"de jure": in law.
"de facto": in reality.

A government passes a law that as of now, nobody may breathe. De jure,
people no longer breathe. De facto, however, they still do.

In other words, they are committing a crime. I fail to see how that
relates to what we're discussing here.

Look, I feel like I'm arguing with a complete idiot, and you're going to
have to work pretty hard to change my mind. You *ASKED* for an explanation
of "de facto", and I gave you one, complete with an illustration. What's
more, it is clear that the distinction is highly relevant.

*IN LAW*, C99 is the current Standard. *IN PRACTICE*, here you are,
advocating C99 and saying that C90 is obsolete, but according to your last
article you don't even have a conforming C99 implementation on your
desktop machine!

De jure, C99
is the C Standard. De facto, C90 is the C Standard.


They're both C standards; the latter is the *current* standard;

De jure, C99 is the C Standard. De facto, C90 is the C Standard.

Is that so hard to understand for you? I mean, I know you struggled with
the terminology, but I have now explained that. Do you *have* to struggle
with the common sense, too? Are you really so foolish as to believe
there's any point in trying to write code that adheres to a Standard to
which not even your own implementation conforms?

<snip>

I don't know exactly which platforms are supported by C99
implementations,

Then you are in no position to make an argument about C99's portability
or otherwise.


I am if my standards of portability comprise an implementation being
portable among a number of fairly popular and widely used OSs, and if
there are implementations for C99 that target those platforms.

That's a lot of ifs.

but let's name five (random) platforms for
illustration:

- Windows
- Linux
- Mac OS X
- Solaris
- HP-UX

By what I'd call "common standards," something that is portable among
that much platforms is very portable.

I think the OS390 and VM/CMS folks might cough and splutter a bit if
they heard you say that.

Surely, they probably have different opinions on portability.

The ones I've worked with are red-hot on portability. I've done a lot of
work on OS390 projects, and normal practice is to write it on the PC, get
it working, then put it straight up on the mainframe for testing. The
ideal is for no code changes to be required on the mainframe - this is
rarely attained, but any such changes that do turn out to be necessary are
made *ON THE PC*, tested there, and then ported up.

But since you don't actually know whether the
platforms you name have C99 implementations available for them, your
point lacks force.


Again:

Not if my standards of portability comprise an implementation being
portable among a number of fairly popular and widely used OSs, and if
there are implementations for C99 that target those platforms.

Again, that's a lot of ifs. You're talking through your nose and hoping
that the facts support you, instead of checking and presenting the facts.


then yes, of
course C99 is portable. But if you mean "implementations exist for
the vast majority of platforms", then I would argue that it isn't.

That in turn depends on what you mean by "the vast majority of
platforms." Do you mean "from microchips to supercomputers"? Or do you
mean "any popular OS"? I would expect most people in general to mean
the second.

I would certainly include mainframes and mid-range computers, which you
seem to have ignored completely.

Yes, because they are of no interest to me.

Well, there's a shock. Nevertheless, there's a lot more to life than Vista.

<snip>

For people not trying to run programs on toasters, C99 is surely
portable enough.

Do *you* use a conforming C99 implementation? You probably don't -
but maybe, just maybe, you do. Most people, however, don't.

Like I've told you before, I use GCC's non-conforming C99
implementation.

So no, then. If C99 isn't even portable to *your* desktop, it is hard to
see how you can sustain a claim to general portability.

I use C99 for my desktop.

That's a change from your last article, where you claimed you did not use
C99 for your desktop. I don't count non-conforming implementations, since
they don't implement C99.

Where do you get that "C99 isn't even portable to my desktop"?

From your own claim that you don't use a C99 implementation.

But the important thing is not so much the conformance
level,

The important thing to you, maybe - but here, we discuss ISO C, not
notquiteISO C.

I'm not discussing "notquiteISO C."

That's exactly what you're discussing, when you talk about non-conformiong
implementations.

I'm stating that the important
thing is not so much the conformance level, but the compiler's
usability.

Usability is important, but rarely an issue. Compilers are normally pretty
easy to use. But if the implementation *doesn't conform*, then you can't
trust it to run code that wasn't tailored specifically for it.

but the compiler's usability. For example, lcc-win doesn't
conform, but it has the most useful set of extensions I've ever seen
on any compiler.

If it doesn't implement the language correctly, the extensions are a
moot point.

That's your opinion (and apparently only yours).

I think you'll find a wide body of support for the opinion that compilers
ought to be able to translate programs according to spec, if only you're
prepared to take your blinkers off.

<snip>

So you see, "conforming" != "perfect".

You seem to be arguing that it's the compiler's fault if the program is
incorrectly written. I don't agree.


It's the compiler's decision what to do when a has something in it
invokes undefined behavior.

Actually, very often the compiler *doesn't* make that decision. For
example, consider the following code:

void foo(unsigned int *a, unsigned int *b)
{
*a += ++*b;
}

This code is standalone, in the sense that one could legally compile it as
a separate translation unit. Do you see any reason why a compiler should
decide to insert extra instructions into this function's translated code
to guard against undefined behaviour, especially when the compiler has no
reason to believe that the function will ever be invoked incorrectly?

If a compiler does what I mentioned above
in a case where a program does something that invokes undefined
behavior, I'd deem that compiler useless.

At the very least, it would be a valuable teaching tool.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
.

Relevant Pages

  • Re: Storgae durations
    ... implementations exist, but where almost every platform in existence ... standard you referred to is no longer current. ... I am if my standards of portability comprise an implementation being ... there are implementations for C99 that target those platforms. ...
    (comp.lang.c)
  • Re: The problems in comp.lang.c
    ... Which is standard and accepted. ... varying subsets of C99, while a few claim full conformance. ... but it may be that implementations for DSPs and the ... Well, the example Jacob posted was actually declaring the variable in the for statement rather than just mixed declaration, and that does have portability issues. ...
    (comp.lang.c)
  • Re: Storgae durations
    ... implementations exist, but where almost every platform in existence ... standard you referred to is no longer current. ... I don't know exactly which platforms are supported by C99 ... each person's definition and standards of portability. ...
    (comp.lang.c)
  • Re: pascal equivalent of python "sleep"
    ... portability problems which exist in Pascal are simply ... Pascal has a standard, the ISO 7185 standard. ... the Borland series implementations. ... What areas should be covered by standard libraries? ...
    (comp.lang.pascal.misc)
  • Re: Why do you like C more than other programming languages?
    ... there are too few conforming C99 implementations for its ... doesn't compile, whereas it compiles just fine on system C but doesn't ... not in accordance with the requirements of the Standard). ...
    (comp.lang.c)