(e-mail address removed) said:
You're wrong. It's that simple.
So you're implying that someone can be right /and/ wrong at the same
time, regarding the same subject? I don't share your reasoning.
I'm well aware that the number of Standards exceeds one.
Finally.
Whether that is true depends on what you mean by the word "current". In
theory ("in law", if you like), you're right - C99 /is/ the current
Standard. In practice, you're wrong - C90 is the current Standard, because
that's the one which is conformed to by the implementations that people
actually use.
What people would those be? I've seen more people use C99 than C90.
So, even though I don't agree with the "de jure," "de facto," "in
theory" and "in practice" stuff, C99 would be the current standard
even in the way you mean it.
I'm sure I have already explained this to you at least twice.
Neither did I claim that you had said that.
Well, you said
"*IN PRACTICE*, here you are, advocating C99 and saying that C90 is
obsolete, ..."
I was regarding C89 as interchangeable with C90 in this context.
So would I. So we are, after all, in agreement. Good.
Logic. You are advocating C99. You claim to use gcc, which is not a C99
compiler.
It is.
Either you have a C99 implementation on your desktop machine or
you don't.
I do.
To have such an implementation on your desktop and yet not even
mention it, let alone claim to use it, even at such a late stage in a
debate on C99, would be very strange behaviour. I deduce that the balance
of probability is that you don't have a conforming C99 implementation on
your desktop. I can only think of two other options, neither of which is
very complimentary to you, so I'd rather avoid them if I can.
I don't think mentioning the programs installed on my computer is
relevant to this discussion. If you think it's relevant in the sense
that I need to prove that I have a C99-conforming implementation
available in my machine: you can see my headers; I'm on Linux. There
are C99-conforming implementations for Linux. There, was that so hard?
But the point is that you did not have a valid reason to believe I
didn't.
That's precisely what "conforming" means.
"6 The two forms of conforming implementation are hosted and
freestanding. A conforming hosted implementation shall accept any strictly
conforming program. A conforming freestanding implementation shall accept
any strictly conforming program that does not use complex types and in
which the use of the features specified in the library clause (clause 7)
is confined to the contents of the standard headers <float.h>, <iso646.h>,
<limits.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>. A
conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any
strictly conforming program."
I don't see the word "perfect" in there.
There's no room in there for imperfection. Either an implementation
conforms or it doesn't.
Of course. Saying "this implementation conforms, but it doesn't," is a
null statement. And I've never said anything like that. BTW, what does
that have to do with an implementation being or not being perfect?
It depends on what you mean by "current".
Apparently we're never going to agree on what "current" means.
On that, we can agree.
I have seen no evidence so far that you have *even* one (C99-conforming)
implementation.
Like I mentioned above, I'm currently on Linux. You can find out for
yourself which conforming implementations there are if you are so
interested.
If your code doesn't need to be portable, I agree. But if your code doesn't
need to be portable, why do you care in the first place?
That depends on what you mean by portable. Do you mean "from
microchips to supercomputers"? Or do you mean "any popular OS"? I
think I shouldn't have to mention any further that your standards of
portability are radically different from mine.
Also, in the case of GCC, they implement it closely enough that I've
never even had to read their site about C99. So I've been writing
standard C without worrying about what GCC supports or not, which
proves that using GCC doesn't limit the code to be compiled only under
GCC. So the code's portability is not reduced at all.
No, it's a lot of ifs. It doesn't prove anything at all. 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.
The availability and installation of C99 implementations on your targets.
Provided your portability needs are very modest and provided that you don't
need to port to platforms where those needs are not met, yes. That's a
little like saying you have a brand-new widget that is really useful, and
okay, you know it needs a special kind of power source, but you can use
your widget ANYWHERE that this special power source is available. True
enough, but it doesn't actually say much.
Those who program in the common subset of C90 and C99 genuinely don't need
to know on which platforms their code will be compiled,
What people would those be? We're discussing the portability of C89/
C90/C99 here, but we both know that out there in the real world this
isn't as relevant as it may sound here. I hardly can think of any
serious program that has the fortune of being able to restrict itself
to pure standard C. Want to hit the net? Want to flow through more
than one thread of control? Want to draw a window on the screen? Want
to start another process? Want to handle directories? There you go
your (completely) non-portable code. I at least have never had the
chance to write a (serious) program in standard C. Have /you/? Have
you ever developed production code in which you only write to a few
streams, do some math operations, do some text processing, and finally
display a nice "exiting" message?
because any
platform that can support C code at all is going to have a C90
implementation available for it, and by sticking to the common subset they
avoid the risk of the code /not/ compiling because someone out there
actually happened to have a C99 implementation.
Well, I suppose I should thank heaven for small mercies.
Very true. But I'm not concerned with those who have the /same/ interests
as me. I can be absolutely sure that they will be able to compile my code,
because they'll have the same system as me. I'm far more concerned with
those who have /different/ interests to me. If they can't compile my code
too, that's a big problem.
No, they don't.
Yes, they do.
You can't be a little bit pregnant. Either you're pregnant or you're not.
But a glass of water can be a little full. I'd say my analogy applies
better than yours, but that's something we're never going to agree on,
are we?
The more I read this, the more I think you've never actually ported code in
your life.
I have, just not in the same way as you.
No, you can't, because the bits of C99 that *your* implementation
implements correctly might not be the same as the bits of C99 that the
other guy's implementation implements correctly.
But that wasn't my point. My point was, again: you can use safely the
subset of the language that the implementation implements; you just
have to know what you can use and what not. And *that* isn't going to
make the code any less portable, since it will later be compilable
under any conforming implementation. If you use extensions, then sure,
you're limiting the code to be compilable only under that specific
compiler, but that's not what I mentioned.
The issue here is
portability. A program is (minimally) portable if it can be compiled and
executed correctly (without source code changes) on at least two
implementations. If those two implementations disagree about the semantics
or legality of a construct used by the program, then the program is *not*
portable (without source code changes) between those two implementations.
You're talking as if I said anything about extensions.
The more implementations that translate the program correctly and with
identical semantics (without source code changes), the more portable the
program. There are those for whom portability is really, really, really
important, and for them, perfection in conformance - whilst admittedly an
unattainable ideal - is nevertheless vastly important, and "misses out
whole chunks of the Standard" doesn't count as being even remotely close
to what is required. The conformance of gcc, Visual Studio, Borland C,
Intel C, Digital Mars C, C/370, LE370, XL C, Norcroft C, CodeWarrior - and
plenty of other compilers - to C90 is astoundingly good, making C90 the
Standard of choice when writing code intended to be portable.
Sure, and nobody has claimed otherwise as far as I'm aware - but
compiler-specific extensions are not topical here. Similarly, I have on my
desk a fret brush. It's in a tube marked "ghs Fast-Fret" ("Glides on,
wipes off, cleans strings, lets you play faster, brightens sound, prolongs
fingerboard life, long-lasting, won't damage finish, won't soil or stain,
can't spill or break".) Very useful indeed, and I use it regularly. But
it's hardly relevant in comp.lang.c, is it? Same applies to
compiler-specific extensions.
You went more off-topic in that paragraph than I went on mentioning
the words "compiler-specific extensions." So I have to ask: Why do you
talk about your toy on comp.lang.c?
And actually, the standard talks about compiler-specific extensions.
So it *is* relevant to comp.lang.c. It's simply not appropriate to
discuss them in detail, which I didn't. The standard, however, doesn't
mention anything about objects hanging around on your desk.
If it isn't conforming, it isn't a C compiler.
Yes, it is. It simply isn't conforming. Hence the phrase "non-
conforming C implementation."
If it conforms to C90 but
not to C99, it's a C90 compiler but not a C99 compiler. gcc currently
falls into that category.
GCC is both a C90 and C99 implementation. It conforms to C90, but it
doesn't conform to C99.
You avoided the question. Why did you avoid the question?
The function won't always invoke undefined behavior, so I thought I'd
bring up a more relevant and illustrative example. But anyway, what if
we modified the function so that it did something that would *always*
invoke undefined behavior? What do you think the compiler should do
then? Do you think I'd be OK for it to erase all files in the hard
disk?
But it doesn't. It's on the edge of doing so in two ways, but it doesn't
*actually* invoke undefined behaviour.
It is required to increment p. The code is strictly conforming.
It must increment the pointer. What it hopes is its own affair.
No, because the code is strictly conforming and doesn't have any "erase all
files" semantics.
I agreed no such thing, since the code is strictly conforming.
Sorry; I thought it would undoubtedly invoke undefined behavior.
Their productivity will increase if they have learned to avoid invoking
undefined behaviour unintentionally.
The world isn't perfect. Even the most experienced programmer will
make mistakes and invoke undefined bahavior.
Presumably you define "serious programmer" as "programmer who
unintentionally invokes undefined behaviour on a regular basis".
No. In this context, I meant it more as "a programmer that needs to be
as productive as possible, and thus needs the best possible tools
available, and a compiler that doesn't erase all files in the hard
disk at the first sign of undefined behavior is the very minimum
requirement."
Sebastian
