Multi precision floating point

[Harald van Dijk]

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

I believe you and jacob navia said the same thing here.

(KT wrote)

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

Yes. It is possible for a compiler to support operator overloading in a
way that won't miscompile any correct standard C program.

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.

There is not a single ISO C compiler that doesn't have any extensions,
nor will there or can there ever be for the current and previous
standards. Extensions are required to write the standard headers.

 

[James Kuyper]

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

(KT wrote)

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


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.

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.

If not, then Keith is correct. When your compiler is operating in
whatever mode it needs to be in to support operator overloading, in that
mode it does in fact compile a language which is not actually C, though
it may be similar.

 

[Flash Gordon]

Harald van Dijk wrote, On 01/12/07 10:24:

Such programs exist.

<snip example>

Make it that it only treats a program as Fortran if it is not a valid C
program and Keith's point still stands.

 

[Flash Gordon]

Keith Thompson wrote, On 01/12/07 02:44:

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

This is closely related to my question which Jacob has not addressed.
His compiler (like most) has two modes, one which claims conformance to
the C standard and one which does not. When it does not claim
conformance it can do anything Jacob likes, and that is not relevant
here. However, Jacob has claimed his operator overloading is compatible
with the standard, so does his compiler accept operator overloading when
in the mode that conforms to the standard?

 

[Richard Heathfield]

jacob navia said:

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.

Please discuss such extensions in a newsgroup devoted to that
implementation. If the OP wants to use lcc-win32 extensions, no doubt
he'll ask in a newsgroup devoted to that implementation.

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

The Standard requires a diagnostic message to be produced for such code. If
lcc-win32 does not produce such a message in conforming mode, then
lcc-win32 itself is not conforming. (If it does, of course, there is no
problem.)

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

If a program written to use those extensions is a correct C program, then
it will compile and work correctly under other C compilers, not just
lcc-win32. If it does not, then it is not a correct C program, and so
either it is an incorrect program or it is a correct program written in
some other language, in which case it should be discussed in the group
appropriate to that language.

This isn't an academic exercise. People need to be aware that, by using
your extensions, they are locking their code in to your implementation.

 

[jacob navia]

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

This would mean that I am allowed to use the operator overloading
extension (and stop all internal contorsions) in conforming mode,
what would allow me to implement completely complex types and
extended precision types in the same fashion and take that code
OUT from the compiler...

The only difficult point comes to initialization.

C99 declares that

double _Complex val = 568.67+78.87*I;

is a complex number. There is no accepted way to do
this by using operator overloading either in C or C++...

Somehow the compiler has "to know" those types. The same for
the extended precision floats:

qfloat m = 4544666788766544545455454e9567Q;

(Note the 'Q' at the end)

I would have to design some kind of syntax to call a user function
during compile time to parse this kind of new numbers.

#pragma NumberLexer('Q',qfloat,ReadQfloat,"Qfloat.dll")

mening:

"When you find a number that ends in 'Q', call the function ReadQfloat
in the "Qfloat.dll". That function will fill the qfloat type using the
parsed number.

In a Unix environment it would be:
#pragma NumberLexer('Q',qfloat,ReadQfloat,"libqfloat.so")

 

[Flash Gordon]

jacob navia wrote, On 01/12/07 11:06:

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

In non-conforming mode you can do anything you want. In conforming mode
you have to issue a diagnostic, but once you have done so you can then
do what you want with the program. That diagnostic could be:
INFORMATION: Operator-overloading extension being used

I have respected the standard by

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

However, your extensions are not valid in that a conforming compiler is
*required* to issue a diagnostic for the construct.

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

That is a matter of opinion.

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

So your operator overloading and anything that relies on it cannot be
used in any compiler that is behaving as the standard requires. It also
cannot be used in a source file that includes the following snippet in
any mode your compiler supports...

#include <math.h>
static int atof;

If there was an implementation that supported your extension at the same
time as meeting all the requirements of the standard you would be in a
stronger position. As it is, however, I would say that
C+Jocobs-Extensions is a different language. The same can be said about
some of the GNU extensions, and I've certainly seen people stating here
that gnuc is a different language.

 

[Richard Heathfield]

Harald van D?k said:

about whether the extension as implemented is allowable in a conforming
implementation, which I believe is topical here.

Well, that's an easy one - the answer is yes, provided that any mandatory
diagnostic message is in fact produced, and provided that it doesn't cause
a strictly conforming program to be mistranslated.

 

[Harald van Dijk]

jacob navia said:



Please discuss such extensions in a newsgroup devoted to that
implementation. If the OP wants to use lcc-win32 extensions, no doubt
he'll ask in a newsgroup devoted to that implementation.

That advise might have been good earlier in the thread, but now, this is
about whether the extension as implemented is allowable in a conforming
implementation, which I believe is topical here.

 

[Harald van Dijk]

Harald van Dijk wrote, On 01/12/07 10:24:

<snip example>

Make it that it only treats a program as Fortran if it is not a valid C
program and Keith's point still stands.

Agreed.

 

[Harald van Dijk]

[...]
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 very interesting.

This would mean that I am allowed to use the operator overloading
extension (and stop all internal contorsions) in conforming mode, what
would allow me to implement completely complex types and extended
precision types in the same fashion and take that code OUT from the
compiler...

The only difficult point comes to initialization.

C99 declares that

double _Complex val = 568.67+78.87*I;

is a complex number. There is no accepted way to do this by using
operator overloading either in C

Correct, obviously.

or C++...

Incorrect. The problem can be avoided by allowing non-constant
initialisers, which is exactly what C++ does.

Somehow the compiler has "to know" those types. The same for the
extended precision floats:

qfloat m = 4544666788766544545455454e9567Q;

(Note the 'Q' at the end)

I would have to design some kind of syntax to call a user function
during compile time to parse this kind of new numbers.

#pragma NumberLexer('Q',qfloat,ReadQfloat,"Qfloat.dll")

Please don't allow arbitrary code to be executed merely by compiling a
program even before it's run. This is a security hole just waiting to be
exploited.

I don't have an alternative suggestion, though.

 

[santosh]

[...]
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 very interesting.

This would mean that I am allowed to use the operator overloading
extension (and stop all internal contorsions) in conforming mode,
what would allow me to implement completely complex types and
extended precision types in the same fashion and take that code OUT
from the compiler...

The only difficult point comes to initialization.

C99 declares that

double _Complex val = 568.67+78.87*I;

is a complex number. There is no accepted way to do this by using
operator overloading either in C

Correct, obviously.

or C++...

Incorrect. The problem can be avoided by allowing non-constant
initialisers, which is exactly what C++ does.

Somehow the compiler has "to know" those types. The same for the
extended precision floats:

qfloat m = 4544666788766544545455454e9567Q;

(Note the 'Q' at the end)

I would have to design some kind of syntax to call a user function
during compile time to parse this kind of new numbers.

#pragma NumberLexer('Q',qfloat,ReadQfloat,"Qfloat.dll")

Please don't allow arbitrary code to be executed merely by compiling a
program even before it's run. This is a security hole just waiting to
be exploited.

But many languages have a compile-time language that allows this sort of
thing and more. This shouldn't be a security risk under an operating
system with decent security protections in place.

 

[santosh]

The languages I know of that do, are designed to compile and run on
the same machine. With C, this is often not so. It should be safe to
compile a program on one machine, and run it on another where
potentially malicious code can do no harm.


If it can wipe my home directory, I do not care much whether my OS's
security protections would prevent it from wiping the whole system. If
there are other security protections you're thinking about, that would
completely prevent any file writing, then it would be okay at least
with me.

When you download any source from the Net and compile it, what guarantee
do you get that the configure or make process doesn't wipe your home
directory? Or do you compile everything in a chroot jail?

 

[Richard Harter]

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

Well, yes and no. In the original meaning of the word, there is
no consensus, the original meaning being a general accord or
common agreement. Over time a second usage has become common,
typically something like majority agreement. Neither of these
usages apply here. Instead there is a minority of the posters
(the regulars) who have a consensus between themselves about what
is on and off topic in c.l.c. This consensus does not extend to
all people who regularly post to comp.lang.c, nor does it stop
"regulars" from being "off topic".

In short there is a consensus among those posters who agree with
you.



Richard Harter, (e-mail address removed)
http://home.tiac.net/~cri, http://www.varinoma.com
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die

 

[Harald van Dijk]

But many languages have a compile-time language that allows this sort of
thing and more.

The languages I know of that do, are designed to compile and run on the
same machine. With C, this is often not so. It should be safe to compile
a program on one machine, and run it on another where potentially
malicious code can do no harm.

This shouldn't be a security risk under an operating
system with decent security protections in place.

If it can wipe my home directory, I do not care much whether my OS's
security protections would prevent it from wiping the whole system. If
there are other security protections you're thinking about, that would
completely prevent any file writing, then it would be okay at least with
me.

 

[Mark McIntyre]

I believe you and jacob navia said the same thing here.

No offense, but that may be because you don't speak english as a first
language.

When you extend something, you go beyond its original scope. When you
integrate something into another thing, you make it a part of it. Jacob
cannot make operator overloading part of the C language, since the
language is codified by ISO.

There is not a single ISO C compiler that doesn't have any extensions,

This may be true, but it doesn't mean that any of these compilers have
integrated (for example) the keyword __declspec or dynamic linking into
the language.

nor will there or can there ever be for the current and previous
standards. Extensions are required to write the standard headers.

Quite possibly. But irrelevant.

 

[Harald van Dijk]

When you download any source from the Net and compile it, what guarantee
do you get that the configure or make process doesn't wipe your home
directory? Or do you compile everything in a chroot jail?

The configure and make processes don't need to be run on the same system
as the compiler. Do a search for distcc, if you're interested.

 

[Harald van Dijk]

No offense, but that may be because you don't speak english as a first
language.

No offense taken, but I don't think that's it. See below.

When you extend something, you go beyond its original scope. When you
integrate something into another thing, you make it a part of it. Jacob
cannot make operator overloading part of the C language, since the
language is codified by ISO.

He indeed cannot make operator overloading part of ISO C, but he can make
operator overloading part of the language accepted by his conforming
implementation of ISO C. In context, this interpretation of "the
language" makes more sense, I believe. Apparently you didn't read it that
way, but Jacob has (to my knowledge; feel free to correct) never extended
ISO C. He started from a C90-based compiler which already supported a few
extensions, and continued to add parts of C99. He has at no point had a
compiler which accepted exactly ISO C99 as specified by the standard, so
he has never extended that standard C language.

This may be true, but it doesn't mean that any of these compilers have
integrated (for example) the keyword __declspec or dynamic linking into
the language.

Correct, but why does that matter?

Quite possibly. But irrelevant.

Why do you now tolerate some extensions of some conforming
implementations, but not others of equally conforming implementations?

You claimed "once you add extensions, you no longer have ISO C." Would
you like to take that back?

 

[jacob navia]

[...]
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 very interesting.

This would mean that I am allowed to use the operator overloading
extension (and stop all internal contorsions) in conforming mode, what
would allow me to implement completely complex types and extended
precision types in the same fashion and take that code OUT from the
compiler...

The only difficult point comes to initialization.

C99 declares that

double _Complex val = 568.67+78.87*I;

is a complex number. There is no accepted way to do this by using
operator overloading either in C

Correct, obviously.

or C++...

Incorrect. The problem can be avoided by allowing non-constant
initialisers, which is exactly what C++ does.

No, they will be called at program initialization time, i.e. at the
startof the program.

I want to call those initializers at COMPILE time, i.e.
call that function from the compiler and then just store the binary
result in the data section of the program

Please don't allow arbitrary code to be executed merely by compiling a
program even before it's run. This is a security hole just waiting to be
exploited.

I don't have an alternative suggestion, though.

Well it doesn't have to be a binary. The compiler could compile some
function, then link it then execute it.

 

[Mark McIntyre]

He indeed cannot make operator overloading part of ISO C, but he can make
operator overloading part of the language accepted by his conforming
implementation of ISO C.

Agreed - but this language is not ISO C.

In context, this interpretation of "the language" makes more sense, I believe.

In the context it was written, the language referred to was surely C.
And since the topic of this group is ISO C, it seems entrely reasonable
to infer that it was this sort of C to which JN referred, not LCC-Win32
or gcc, or msvc or whatever.

Why do you now tolerate some extensions of some conforming
implementations, but not others of equally conforming implementations?

You mistake me. I tolerate them all. I however don't refer to them as
ISO C - they're extensions of ISO C.

You claimed "once you add extensions, you no longer have ISO C." Would
you like to take that back?

Please don't be disingenuous. What a compiler implementer does under the
hood, eg inside standard headers, is not constrained by the Standard.