good c compiler

[Keith Thompson]

Why not just use ^ for exponentiation? For when the left operand is
floating point:

i^j; i xor j
x^n; pow(x,n)

Because integer exponentiation is also useful. If "^" is just a
synonym for pow(), it doesn't give much value over just calling pow();
the pow() function can already optimize for the case where the right
operand is an exact integer.

 

[Keith Thompson]

There's a reason I used the word "arithmetic" ...

However, this was not intended as a serious proposal; merely as an
example of an extension that might be possible to shoehorn into a
compiler without breaking any existing code versus one that _does_
cause breakage, since Jacob seems unable to distinguish between them.

If we're just talking about the legality of a hypothetical
compiler-specific extension, it might be easier to recognize two
consecutive "*" tokens as an exponentiation operator, but only when
there's a syntax error without this interpretation. In addition, you
could issue a warning or error message if a pair of "*" tokens
interpreted as an exponentation operator are separated by whitespace
or a comment (or, of course, if it's used in a context where an
exponentiation operator is invalid). It's not a very clean design,
but it's less likely to break valid code.

This is *not* a serious proposal, just an idle exploration of what's
allowed by the standard.

 

[vippstar]

How about borrowing from other languages? Allow operators to be used as
functions: +(2, 3) == 2 + 3. Then make pow an operator: pow(2, 3) ==
2 pow 3. (I don't necessarily think this is a good idea; I haven't given
it a lot of thought. I like it at first glance though.)

What'd be the type of +?
What would the result of this be:

1 + (2, 3)

In C, as it is defined by ANSI/ISO in the standards, it's 4.

 

[CBFalconer]

.... snip ...

If accepting means to translate without emitting a diagnostic
error, you are correct. However, the standard seems to use the
word 'accept' to talk about the implementation processing the
file. In that sense, no, it's not horrible as a C90 compiler is
*required* to accept files containing // comments.

I don't think you meant what you wrote. A C90 compiler is required
to accept the '/' as indicating division. Two in a row are a
syntax error, not a comment, and require a diagnostic.

 

[CBFalconer]

Why not just use ^ for exponentiation? For when the left operand
is floating point:

i^j; i xor j
x^n; pow(x,n)

Think about parsing:

j = (int)x ^ n;

 

[CBFalconer]

.... snip ...

If we're just talking about the legality of a hypothetical
compiler-specific extension, it might be easier to recognize two
consecutive "*" tokens as an exponentiation operator, but only
when there's a syntax error without this interpretation. In
addition, you could issue a warning or error message if a pair
of "*" tokens interpreted as an exponentation operator are
separated by whitespace or a comment (or, of course, if it's
used in a context where an exponentiation operator is invalid).
It's not a very clean design, but it's less likely to break
valid code.

I often write:

int foo(char* *p) { ...

just to make clear what the parameter is. To my mind.

 

[Keith Thompson]

Keith Thompson wrote:
... snip ...

I often write:

int foo(char* *p) { ...

just to make clear what the parameter is. To my mind.

Which wouldn't be affected by my suggestion (which, let me emphasize
again, was not a serious one). Either ** or * * would be interpreted
as an exponentation operator only in cases that are currently syntax
errors. Since "int foo(char* *p)" is already valid, it would be
unaffected.

 

[Harald van Dijk]

What'd be the type of +?

It wouldn't have a type.

What would the result of this be:

1 + (2, 3)

In C, as it is defined by ANSI/ISO in the standards, it's 4.

It would remain unaffected. Your point is a good one, but the example
should use unary plus: the value of +(2, 3) is currently already defined
as 3, not 5.

 

[Nick Keighley]

I don't see how or why this is a good idea.  What's wrong with simply
choosing one conforming compiler and making sure to invoke it in
standards-compliant mode?  Simply running gcc with
the -Wall -pedantic -ansi options should help the poster distinguish
between C and any implementation-specific extensions, and he won't have to
waste effort of installing, learning, and maintaining two separate
compiler distributions.

in an ideal world a single "perfect" compiler would suffice.
The Perfect Compiler would diagnose all syntax and constraint errors.
It would warn about the use of any extension and even warn about
dubious or potentially error prone constrcuts. Unfortuatly no such
compiler exists 9not even gcc with all those flags) so using a
selection of compilers (and maybe other tools like lint) gets you
closeer
to the Perfect Compiler.

And I think it's a bit of a stretch to imply that the GCC folks try to lock
customers into using their product -- it's free to distribute and even to
modify into a very different product.  Unlike vendors of proprietary
systems, they don't stand to benefit much from customer lock-in, except to
the degree that the community at large benefits from wider adoption of
their system.

We recommend, rather, that users take advantage of the extensions of
GNU C and disregard the limitations of other compilers. Aside from
certain supercomputers and obsolete small machines, there is less
and less reason ever to use any other C compiler other than for
bootstrapping GNU CC.
(Using and Porting GNU CC)

-pedantic
This option is not intended to be useful; it exists only to satisfy
pedants who would otherwise claim that GNU CC fails to support the
ANSI standard.
(Using and Porting GNU CC)

 

[Nick Keighley]

People who develop for Windows generally don't care that much about
portability.  You can argue this or accept it or disagree or whatever,
but it remains true.  It is not universally/mathematically true of
course (I'm sure you will find me the counter-example; some guy
somewhere who makes the assertion not universally true).

But the fact remains that Windows developers routinely lock themselves
into the latest flavor-of-the-month from MS; it doesn't seem to bother
them much.

I sometimes use Windows as a test platform. That is, the final target
is intended to be something else but the code is, partially, tested
under Windows. Windows being a readily available platform. So this
isn't "windows developemnt" per se but does involve using
a Windows hosted platform to develop reasonably portable code. So I
care about extensions.

You see Kenny- you *can* post sensible things!

 

[Bartc]

Think about parsing:

j = (int)x ^ n;

Parsing isn't affected, except that it may be necessary to use a different
name for ^.

When types of operands are considered, then ^ will be split between xor and
pow().

Your example would use xor.

If you mean it's not possible to take the power of an integer value this
way, then yes this is still a limitation.

 

[James Kuyper]

jacob navia wrote: [...]

For instance, it accepts // comments. Isn't it that HORRIBLE?

As a matter of fact, YES, if the system is attempting to conform to
C90. The result is that the poor user is never told that his code
is not portable with those successive division symbols.

If *and only if* the system is attempting to conform to C90.

But jacob has not, as far as I know, ever claimed that lcc-win
conforms to C90. In the absence of such a claim, the fact that it
doesn't diagnose // comments is no worse than the fact that it doesn't
diagnose REM statements.

True; the problem isn't that he has made any claim that lcc-win fully
conforms to C90 or C99. The problem is that he responds so viciously to
anyone pointing out that it doesn't fully conform. Coming from anyone
else, I would consider such a response to be an implicit (and false)
claim that they do fully conform. I don't know what it means coming from
jacob, but he's at least made it clear that it doesn't mean that. My
best guess is that this is his way of saying "I don't care if it doesn't
fully conform", but the vehemence with which he says it belies the "I
don't care" part.

 

[Keith Thompson]

It wouldn't have a type.


It would remain unaffected. Your point is a good one, but the example
should use unary plus: the value of +(2, 3) is currently already defined
as 3, not 5.

Which is why, if this feature were to be added to the language, you'd
need a distinctive notation for an operator used as a function name.
C++ uses ``operator+(2, 3)'' (though I'm not sure it applies in this
case).

 

[vippstar]

... snip ...



I don't think you meant what you wrote. A C90 compiler is required
to accept the '/' as indicating division. Two in a row are a
syntax error, not a comment, and require a diagnostic.

I did

I mentioned the usage of 'accepting' by the standard (C99 though, not
C90), and it's different than yours in your post.
Accept seems to mean apply TP 1 to 4 to it.
So, a file with // comments must be accepted by a C90 implementation.

 

[jameskuyper]

(e-mail address removed) wrote:
....

I mentioned the usage of 'accepting' by the standard (C99 though, not
C90), and it's different than yours in your post.
Accept seems to mean apply TP 1 to 4 to it.
So, a file with // comments must be accepted by a C90 implementation.

One key problem is that the standard uses the terms "accept" and
"reject" in important ways without defining them. I've heard arguments
that "accept" corresponds to translation phases 1-7; I don't think
that's plausible, but the argument has been made. As far as I can see,
a compiler which generates the message "Program accepted" counts as
having accepted the program, even if it does nothing else with the
program (not even translation phase 1). I don't think that this was
the committee's intent, which is why I believe the wording should be
changed to prevent that from being a valid interpretation.

 

[vippstar]

(e-mail address removed) wrote:

...


One key problem is that the standard uses the terms "accept" and
"reject" in important ways without defining them. I've heard arguments
that "accept" corresponds to translation phases 1-7; I don't think
that's plausible, but the argument has been made. As far as I can see,
a compiler which generates the message "Program accepted" counts as
having accepted the program, even if it does nothing else with the
program (not even translation phase 1). I don't think that this was
the committee's intent, which is why I believe the wording should be
changed to prevent that from being a valid interpretation.

I agree the standard uses accept in critical sentences without
defining the meaning, but I don't think there's many interprentations
of what the standard means.

I was actually based on your own words when I mentioned TP 1 to 4.
Message-ID: <8ac6eb1c-3e61-404e-9bd7-
(e-mail address removed)>
Message-ID: <5hJtk.966$UX.551@trnddc03>

You seem to contradict yourself...
Would you mind clarifying?

 

[Harald van Dijk]

(e-mail address removed) wrote:
...

One key problem is that the standard uses the terms "accept" and
"reject" in important ways without defining them. I've heard arguments
that "accept" corresponds to translation phases 1-7; I don't think
that's plausible, but the argument has been made.

Do you believe "accept" corresponds to more, or to less translation phases?

Personally, I dislike the idea of treating "A conforming hosted
implementation shall accept any strictly conforming program." as saying it
may refuse to link strictly conforming programs, just because linking
isn't part of "accept". I don't see how "accept" can be meant to refer to
anything less than all 8 phases.

 

[jameskuyper]

I agree the standard uses accept in critical sentences without
defining the meaning, but I don't think there's many interprentations
of what the standard means.

I've been monitoring comp.std.c since 1996, and in that time I've
heard quite a few mutually incompatible meanings for "accept" being
proposed as the only possible meaning.

I was actually based on your own words when I mentioned TP 1 to 4.
Message-ID: <8ac6eb1c-3e61-404e-9bd7-
(e-mail address removed)>
Message-ID: <5hJtk.966$UX.551@trnddc03>

You seem to contradict yourself...
Would you mind clarifying?

That message described an absolutely minimally conforming
implementation of C99. My point was to show that there are far fewer
meaningful requirements on such an implementation than you might
think. One requirement is that code which contains a #error directive
which survives conditional compilation must be rejected, with a
suitable error message. That requires essentially full implementation
of translation phases 1-4. Another requirement is that all strictly
conforming programs must be accepted. In itself, that requirement can
be met by a compiler with accepts all programs, regardless of their
contents. In the message I posted today, I was only addressing the
acceptance requirement, not the rejection requirement.

 

[James Kuyper]

Do you believe "accept" corresponds to more, or to less translation phases?

Personally, I dislike the idea of treating "A conforming hosted
implementation shall accept any strictly conforming program." as saying it
may refuse to link strictly conforming programs, just because linking
isn't part of "accept". I don't see how "accept" can be meant to refer to
anything less than all 8 phases.

When you "accept" a gift, does that mean that you need to use it? Do you
even need to unwrap it? As I understand it, I've finished accepting the
gift when I take it into my hands, and say "thank you", even if I toss
it in the trash, still wrapped, as soon as I'm out of sight of the giver.

I don't see any justification for interpreting "accept" for compilers in
any stronger fashion than that. I believe that the committee intended
the term to mean more than that, but I think it's a defect in the
standard that they chose to use the word "accept" to convey that intent,
without giving it any C-specific definition.

 

[Kenny McCormack]

According to your classification of which features are important and
which are not. Other people may well have different opinions. Your
compiler is an impressive piece of work, but I wish you'd stop
pretending that it's complete when you know darned well that it isn't
yet.

Nothing is ever complete. Nor is a painting ever finished.