Multi precision floating point

[CBFalconer]

Keith Thompson wrote:
.... snip ...


No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.

Note that the C standard does NOT forbid extensions

True. However c.l.c does.

 

[Harald van Dijk]

By the same logic, this is C code, since GCC compiles it:

PROGRAM STEFACC
C NUMERICAL METHODS: FORTRAN Programs, (c) John H. Mathews 1994 C

[...]

This is not accepted by any version of GCC in any mode where it aims to
conform to any version of the C standard, and I would be very surprised
if it is accepted by any other compiler in any such mode.

 

[Marco Manfredini]

By the same logic, this is C code, since GCC compiles it:

PROGRAM STEFACC
C NUMERICAL METHODS: FORTRAN Programs, (c) John H. Mathews 1994 C

[...]

This is not accepted by any version of GCC in any mode where it aims to
conform to any version of the C standard, and I would be very surprised
if it is accepted by any other compiler in any such mode.

gcc is not the C-compiler.

 

[Flash Gordon]

Ian Collins wrote, On 30/11/07 22:51:

Just like gcc?

No.

Jacob is claiming that his compiler with its extensions conforms to the
standard, to do that it would have to have the extensions enabled whilst
*in* standards compatible mode.

gcc does not claim its extensions are compatible with the C standard,
and where they are not disables them when you tell it to conform to the
standard. Also no one is claiming that gcc+gnu extensions conforms to
the C standard.

Note that I am *not* complaining about the default mode not conforming
to the standard (that applies to most C compilers) nor about the
presence of extensions in a compiler, just querying whether as Jacob
says this extension is compatible with the standard it is enabled when
his compiler is instructed to conform to the standard.

 

[jacob navia]

By the same logic, this is C code, since GCC compiles it:

[snip fortran code]

All extensions and proposals that I have argued over and
over produce always this brainless answers...

BRAVO user923005!

Your arguments show the sophistication your mind is capable of!

 

[jacob navia]

Just like gcc?

And MSVC:

__declspec(dllimport)

_stdcall

etc etc.

And IBM with their vector extensions...

And ANY compiler that existed since ALL of them had
extensions, and without those extensions many of the standard
things today would never had existed!

 

[jacob navia]

Since the result is a library to go with the non-C capabilities of
lcc-win32, that doesn't matter, and is of negligible interest on
c.l.c. In fact, probably off-topic.

I would say that your answer is of negligible interest anyway...

 

[jacob navia]

True. However c.l.c does.

You are speaking for yourself... There is no approved c.l.c
consensus about this.

 

[jacob navia]

By the same logic, this is C code, since GCC compiles it:

PROGRAM STEFACC
C NUMERICAL METHODS: FORTRAN Programs, (c) John H. Mathews 1994 C

[...]

This is not accepted by any version of GCC in any mode where it aims to
conform to any version of the C standard, and I would be very surprised
if it is accepted by any other compiler in any such mode.

That doesn't matter Mr 923005... Important is just to
say something, even if it is nonsense.

 

[user923005]

By the same logic, this is C code, since GCC compiles it:

[snip fortran code]

All extensions and proposals that I have argued over and
over produce always this brainless answers...

I would not say that your answers are brainless.

BRAVO user923005!

I am glad that you are capable of understanding that extensions to a
compiler do not extend the language, but simply create an incompatible
superset that is useful for additional purposes.

Your arguments show the sophistication your mind is capable of!

Thank you, but it was nothing.

 

[Keith Thompson]

No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.

Note that the C standard does NOT forbid extensions

You're right. As long as your extension doesn't affect the behavior
of any strictly conforming program (and as far as I know it doesn't),
it's specifically allowed by the standard (C99 4p6).

I have a question (one that you may have answered before, but I've
forgotten the answer). Is this extension supported in conforming mode
(with "-ansic")? Though the standard permits this, IMHO it would be a
good idea to have *some* mode in which extensions are disabled, to
make it easier for programmers to write portable code and detect
non-portable code.

 

[Keith Thompson]

Keith Thompson wrote: [...]
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.

Note that the C standard does NOT forbid extensions

By the same logic, this is C code, since GCC compiles it:

PROGRAM STEFACC
C NUMERICAL METHODS: FORTRAN Programs, (c) John H. Mathews 1994 [232 lines deleted]
RETURN
END

Surely you could have made that point without posting 236 lines of
Fortran.

 

[Keith Thompson]

Keith Thompson wrote: [...]
3) Using operator overloading, I integrated this library
like a basic type into the language.
Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.

Note that the C standard does NOT forbid extensions

By the same logic, this is C code, since GCC compiles it:

[snip fortran code]

All extensions and proposals that I have argued over and
over produce always this brainless answers...

BRAVO user923005!

Your arguments show the sophistication your mind is capable of!

Yes, they do, but not in the way you mean. (Once again, *please* stop
trying to use sarcasm; you just don't have the knack.)

It's been stated in this thread that a Fortran program is not actually
accepted by gcc in a mode in which it acts as a conforming C compiler.

But consider a hypothetical compiler that (a) acts as a conforming C
compiler (let's say it's a fully conforming hosted C99
implementation), and (b) also acts as a conforming Fortran compiler.
Unless there are programs that are simultaneously legal C and legal
Fortran, but with different semantics, this is entirely possible. In
fact, it could easily be implemented as a wrapper that invokes a C
compiler for C programs, and a Fortran compiler for Fortran programs.

The handling of the full Fortran language in this manner can be viewed
as an *extension* provided by a conforming C implementation. As long
as this extension does not alter the behavior of any strictly
conforming C program, it's permitted by the standard. Thus, a
conforming C implementation *can* compile Fortran, and user923005 made
a valid point.

Similarly, a conforming C implementation *can* compile a C-like
language that incorporates operator overloading.

Incidentally, I don't believe that a C program can use operator
overloading without violating either a constraint or a syntax rule.
My understanding is that the existence of an extension does not
relieve the compiler of its obligation to issue a diagnostic for any
such program; after issuing the diagnostic, it's then free to go on
and handle the extension as it likes. (Of course, this applies only
in conforming mode; a compiler is perfectly free to *silently* accept
operator loading, or do anything else it likes, in a non-conforming
mode.)

So, in conforming mode, a compiler can either (a) reject the use of
operator overloading, or (b) accept it, but only after issuing a
diagnostic. Failure to issue the diagnostic would be a violation of
the standard.

(This is a fairly subtle argument, and it's possible that I'm
mistaken, but it was the result of a discussion in comp.std.c.)

 

[santosh]

No. All this extensions are compatible with the C standard as I
have explained thousand times in this newsgroup.

Note that the C standard does NOT forbid extensions
By the same logic, this is C code, since GCC compiles it:

PROGRAM STEFACC
C NUMERICAL METHODS: FORTRAN Programs, (c) John H. Mathews 1994
C

[...]

This is not accepted by any version of GCC in any mode where it aims
to conform to any version of the C standard, and I would be very
surprised if it is accepted by any other compiler in any such mode.

gcc is not the C-compiler.

The GNU documentation says that 'gcc' is still used as a name to the C
compiler within the GNU Compiler Collection (GCC). To compiler
user923005, you'd probably need g77.

 

[Harald van Dijk]

But consider a hypothetical compiler that (a) acts as a conforming C
compiler (let's say it's a fully conforming hosted C99 implementation),
and (b) also acts as a conforming Fortran compiler. Unless there are
programs that are simultaneously legal C and legal Fortran, but with
different semantics, this is entirely possible.

Such programs exist.

/*
*/ #include <stdio.h> /*
*/ int main(void) { /*
*/ puts("This is a C program"); /*
*/ } /*
print *, "This is a Fortran program"
end
*/

 

[jacob navia]

It's possible to extend C in a fully conforming mode. All that's
required is that the extension either selects from among the options
when the C standard leaves the behavior unspecified, or is only
supported for programs that contains specific constructs which render
it's behavior undefined.

Jacob: are you claiming that operator overloading is supported in a
fully conforming mode of your compiler? I don't think that's likely, but
I'm willing to consider the possibility that it's true, but only if you
explain how this is the case.

You can write

int operator = 78;

etc.

"operator" is NOT a keyword. You can use it as a normal identifier.

If you write:

int operator+(someType a,someType b)
{
// ...
}

you are NOT in standard C and I am allowed to treat this non-conforming
code as I wish. For instance, by generating a function that will be
called when you write

someType a,b;

b = b+c;

since this code is AGAIN not conforming (you can't add two user defined
types).

I have respected the standard by

1) No new keywords
2) Only using non-standard constructs for my extension.


It is unfair to treat this extension as a "new language".


When you invoke the compiler with
-ansic however, all extensions are disabled, including
this one. The only exception is _stdcall.

 

[Mark McIntyre]

You mean you've extended the language by adding a new type.

(KT wrote)

No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.

Huh? Things like operator overloading are compatible with ISO C?

Note that the C standard does NOT forbid extensions

Correct.
However once you add extensions, you no longer have ISO C. You have C
with Extensions. Please have the grace to call it that.

 

[Mark McIntyre]

Ian Collins wrote:
(replying to someone)

Just like gcc?

Quite possibly.

Does anyone here claim that gcc is a conforming ISO C implementation?

Does anyone here respond to posts with thinly veiled adverts for gcc?

 

[Mark McIntyre]

All extensions and proposals that I have argued over and
over produce always this brainless answers...

BRAVO user923005!

Your arguments show the sophistication your mind is capable of!

Another example of why people take offense at your posts. You seem
incapable of posting any response that does not contain a personal
attack. Even when you make a valid point, you damage your case by
gratuitous ad hominem comments.

 

[Mark McIntyre]

You are speaking for yourself... There is no approved c.l.c
consensus about this.

I hesitate to bother commenting on that but you're incorrect.
There is a consensus. You may not like it, but its there nonetheless.