Multi precision floating point

[Keith Thompson]

Marco Manfredini wrote: [...]
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.

True, but beside the point:

dcorbit@DCORBIT64 /c/f
$ gcc -c -W -Wall -pedantic stef.f

You're invoking gcc as a Fortran compiler, and you obviously know you're
invoking gcc as a Fortran compiler. The documentation explains how to
invoke it in its C conforming mode.

He's invoking gcc with exactly the same command-line arguments (other
than the file name) that he'd use to invoke it as a C compiler. The
same set of options will also invoke gcc as an Ada compiler, and
probably also as a C++ or Objective-C compiler, depending only on the
source file.

gcc happens to use the source file name (or, optionally, another
command-line option) to determine which language it's going to
compile. It could conceivably look at the contents of the file, in
which case the invocation would be identical (using the file name is
more convenient, and encourages consistent file naming).

Regardless of what gcc actually does, a compiler certainly *could*
correctly compile C and additionally accept Fortran as an extension
(except for the obscure cases where a source file is legal C and legal
Fortran). Pick a non-C language that's entirely disjoint from C, and
that exception goes away. Such a compiler, as long as it issues a
single diagnostic for a Fortran or other non-C source file, could be a
conforming C compiler.

 

[user923005]

[...]
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.
True, but beside the point:
dcorbit@DCORBIT64 /c/f
$ gcc -c -W -Wall -pedantic stef.f
You're invoking gcc as a Fortran compiler, and you obviously know
you're invoking gcc as a Fortran compiler. The documentation explains
how to invoke it in its C conforming mode.

He's invoking gcc with exactly the same command-line arguments (other
than the file name) that he'd use to invoke it as a C compiler. The
same set of options will also invoke gcc as an Ada compiler, and
probably also as a C++ or Objective-C compiler, depending only on the
source file.

Yes, the file name is part of the options, if you don't override it. If
you want to compile C, regardless of file name, there is an option for it
(-x c).

(-ansi or one of the -std options is also required to get gcc to act as a
conforming C compiler, but that doesn't matter here.)

I agree with the rest of what your message, a conforming implementation
*could* accept user923005's Fortran code. However, he suggested that the
code could equally validly be called C code (as a particular extension),
because it was accepted by a conforming C implementation. It isn't.

I definitely never said that. At least, not with a straight face.

 

[Harald van Dijk]

Marco Manfredini wrote: [...]
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.

True, but beside the point:

dcorbit@DCORBIT64 /c/f
$ gcc -c -W -Wall -pedantic stef.f

You're invoking gcc as a Fortran compiler, and you obviously know
you're invoking gcc as a Fortran compiler. The documentation explains
how to invoke it in its C conforming mode.

He's invoking gcc with exactly the same command-line arguments (other
than the file name) that he'd use to invoke it as a C compiler. The
same set of options will also invoke gcc as an Ada compiler, and
probably also as a C++ or Objective-C compiler, depending only on the
source file.

Yes, the file name is part of the options, if you don't override it. If
you want to compile C, regardless of file name, there is an option for it
(-x c).

(-ansi or one of the -std options is also required to get gcc to act as a
conforming C compiler, but that doesn't matter here.)

I agree with the rest of what your message, a conforming implementation
*could* accept user923005's Fortran code. However, he suggested that the
code could equally validly be called C code (as a particular extension),
because it was accepted by a conforming C implementation. It isn't.

There are also other reasons why it might not be considered C code, even
if there does exist a C implementation that accepts it, but this alone is
good enough for me for now.

 

[Harald van Dijk]

I definitely never said that. At least, not with a straight face.

To clarify, I meant "equally valid" exactly as I posted it: I took your
message to mean jacob's extension was no more C than your Fortran code.
If that's not what you meant, then I'm sorry, I misread your message.

 

[user923005]

To clarify, I meant "equally valid" exactly as I posted it: I took your
message to mean jacob's extension was no more C than your Fortran code.
If that's not what you meant, then I'm sorry, I misread your message.

Actually, that's close enough. Compiler vendors are free to add any
extensions that they like to the language. These extensions do not
extend the language. They only extend the capabilities of the
compiler. Adding classes to C, for instance, is no more an extension
to C than adding Fortran to C. Which is not to say that such
extensions are not useful. Only that they are not C.

 

[Keith Thompson]

I agree with the rest of what your message, a conforming implementation
*could* accept user923005's Fortran code. However, he suggested that the
code could equally validly be called C code (as a particular extension),
because it was accepted by a conforming C implementation. It isn't.

There are also other reasons why it might not be considered C code, even
if there does exist a C implementation that accepts it, but this alone is
good enough for me for now.

I wouldn't call it "C code" either, but it is a "conforming program"
as defined in C99 4p7. This just demonstrates that the standard's
definition of a "conforming program" is not particularly useful. (I
think it was added for political, rather than technical, reasons; as
long as we can ignore it, I'm ok with that.)

 

[David Thompson]

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.

You need some semantics beyond those guaranteed by the standard, but
they don't have to actually be extensions. On a bare system with
memory-mapped I/O and some not too unreasonable restrictions on
calling conventions, I think you only need the implementation
definition for pointer computations and conversions.
And in principle you could have an OS which effectively provides
(emulates) the same thing, although I can't think of any that have.

What you can't do is write all of the library _portably_. But
implementation-specific = unportable does not require extensions.

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[David Thompson]

Such programs exist.

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

Not quite. It doesn't work to have the main() routine on the same
effective line as the #include <stdio.h>. You can add a(nother) line
that is blank=comment in the Fortran (fixed) interpretation. Or drop
the #include and either declare puts() yourself -- which is legal as
it doesn't use any header-defined type -- or in C90 you could accept
the implicit declaration, but in C90 you should have a return 0; to
avoid undefined exit status.

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[Harald van Dijk]

You need some semantics beyond those guaranteed by the standard, but
they don't have to actually be extensions. On a bare system with
memory-mapped I/O and some not too unreasonable restrictions on calling
conventions, I think you only need the implementation definition for
pointer computations and conversions. And in principle you could have an
OS which effectively provides (emulates) the same thing, although I
can't think of any that have.

What you can't do is write all of the library _portably_. But
implementation-specific = unportable does not require extensions.

offsetof is required to be defined in the standard headers, not merely
declared, and its definition requires extensions. All possible
definitions that only rely on what standard C calls undefined behaviour
make use of offsetof in a context requiring a constant expression a
constraint violation. So either the syntax must be extended, or a
constraint must not be enforced by a hard error, or an implementation
must rely on the permission that "An implementation may accept other
forms of constant expressions". In all cases, an extension is required.

C99's <tgmath.h> has similar problems.

 

[pete]

offsetof is required to be defined in the standard headers, not merely
declared, and its definition requires extensions.

How can code which isn't required to be written in C language,
possibley require extensions?

 

[pete]

How can code which isn't required to be written in C language,
possibley require extensions?

Let me say that a different way.
If a certain construct that appears in the definition
of a standard library macro is supported by the compiler,
the support of that construct doesn't have to be documented
and shouldn't be considered an "extension".

 

[user923005]

offsetof is required to be defined in the standard headers, not merely
declared, and its definition requires extensions. All possible
definitions that only rely on what standard C calls undefined behaviour
make use of offsetof in a context requiring a constant expression a
constraint violation. So either the syntax must be extended, or a
constraint must not be enforced by a hard error, or an implementation
must rely on the permission that "An implementation may accept other
forms of constant expressions". In all cases, an extension is required.

C99's <tgmath.h> has similar problems.- Hide quoted text -

- Show quoted text -

By the same argument,

i++;

requires an extension in some sense, because it is probably
accomplished using assembly.

The compiler can use any magic it likes to accomplish anything by any
manner. That's not an extension, as long as it is part of the
language. It is highly likely that your compilers memcpy() is
implemented in assembly and not in C, because it may behave more
efficiently given certain conditions like alignments or object sizes.
There's nothing wrong with that and it is not an extension.

An extension is using an unnamed struct. An extension is a type
called qfloat that requires a Q and the end of the data item. An
extension is a string function called strdup(). None of these things
are defined by the language.

There is nothing wrong with any of them. In fact, I like all of
them. But none of them are C language. It should be obvious that
this is true because if you use any of them, then your code is not
guaranteed to compile on a conforming C compiler.

Let's make a simple definition that everyone can agree on:

If it compiles on every ideal, conforming C compiler then it requires
only the C language.
If it fails to compile on any conforming C compiler then it requires
an extension.

 

[Harald van Dijk]

Let me say that a different way.
If a certain construct that appears in the definition of a standard
library macro is supported by the compiler, the support of that
construct doesn't have to be documented and shouldn't be considered an
"extension".

To make sure I'm not misunderstanding, you're suggesting an
implementation might define

#define offsetof(s, m) __special__compiler__magic__offsetof__(s, m)

where __special__compiler__magic__offsetof__ is undocumented? If so, I
would consider that an extension. (And if it is an extension,
documentation is required.) It's an extension even in the most literal
sense of the word -- it extends the language accepted by the
implementation -- and I'm not aware of any alternative definitions by
which it wouldn't be considered one. Could you please explain a bit more?

 

[jacob navia]

An extension is using an unnamed struct. An extension is a type
called qfloat that requires a Q and the end of the data item. An
extension is a string function called strdup(). None of these things
are defined by the language.

There is nothing wrong with any of them. In fact, I like all of
them. But none of them are C language. It should be obvious that
this is true because if you use any of them, then your code is not
guaranteed to compile on a conforming C compiler.

Let's make a simple definition that everyone can agree on:

If it compiles on every ideal, conforming C compiler then it requires
only the C language.
If it fails to compile on any conforming C compiler then it requires
an extension.

If you say that strdup() is an extension, this means that
you get only standard C functions to do anything.

GREAT!

No network
No graphics
No threads
No editors more complex than edlin
No debuggers

Actually your "C" is not able to do anything useful besides
pleasing the regulars in comp.std.c.

 

[Harald van Dijk]

By the same argument,

i++;

requires an extension in some sense, because it is probably accomplished
using assembly.

No, it doesn't require an extension, because it can be interpreted by a
compiler accepting exactly the language as defined by the C standard.

The compiler can use any magic it likes to accomplish anything by any
manner. That's not an extension, as long as it is part of the language.

The definition of offsetof is required to become part of the language
accepted by the implementation, I believe.

It is highly likely that your compilers memcpy() is implemented in
assembly and not in C, because it may behave more efficiently given
certain conditions like alignments or object sizes. There's nothing
wrong with that and it is not an extension.

That depends on how memcpy is defined.

string.h:
// ...
void *memcpy(void *restrict, const void *restrict, size_t);
// ...

string.asm:
_memcpy:
# inefficient assembly implementation
jmp _memmove

In this case, no extension is required, since the assembly version of
memcpy is not read at all by the compiler.

[...]

Let's make a simple definition that everyone can agree on:

If it compiles on every ideal, conforming C compiler then it requires
only the C language.
If it fails to compile on any conforming C compiler then it requires an
extension.

Sure, this means

#include <stddef.h>
struct S {
int m;
};
enum {
zero = offsetof(struct S, m)
};

does not make use of an extension. I can agree on that. But how is
offsetof defined? Let's say it is defined in <stddef.h> as

typedef char __char;
#define offsetof(s, m) ((__char *) &((s *) 0)->m - (__char *) (s *) 0)

Now, after expanding offsetof, it no longer compiles on every ideal,
conforming C compiler. In fact, it violates a constraint which would
cause at least one implementation to reject the program with a hard
error. So by your definition, this _implementation of_ offsetof does make
use of an extension, unless I'm misunderstanding your message.

 

[Philip Potter]

[Why is everyone posting with the EUC-KR character set? And why does
thunderbird insist on viewing that charset with a variable width?]

If you say that strdup() is an extension, this means that
you get only standard C functions to do anything.

GREAT!

No network
No graphics
No threads
No editors more complex than edlin
No debuggers

Actually your "C" is not able to do anything useful besides
pleasing the regulars in comp.std.c.

I don't think Dan was saying anything of the sort. I think he was saying
only objective fact - that if you write something which relies on an
extension, then it may fail to compile on a conforming C compiler. I
don't think you'd disagree with that would you?

I believe that one common technique for using the features that you
correctly point out are not part of standard C is to wrap them into a
small part of your program, and write the main part in Standard C which
calls a wrapper function when it wants to use a nonstandard feature.

This has the benefit of reducing porting effort, since all uses of
nonstandard extensions are limited to one or two modules.

Thus the benefits of using Standard C (portability) and nonstandard C
(functionality unachievable otherwise) are brought together into one
happy medium. But in order to achieve this, it is important to
distinguish between Standard C and extensions. There's nothing wrong
with making such a distinction is there?

 

[user923005]

If you say that strdup() is an extension,

It is an extension.

this means that
you get only standard C functions to do anything.

GREAT!

I agree.

No network
No graphics
No threads
No editors more complex than edlin
No debuggers

Right, the C language does not specify any of those things.

Actually your "C" is not able to do anything useful besides
pleasing the regulars in comp.std.c.

No. My C does everything that I need it to do. I guess that any of
the above jobs will be implemented by some vendor specific library or
even by another standard, if possible.
I do not have any problem with a C compiler that provides a TCP/IP
implementation, an OpenGL implementation, threads. The tools provided
like GUI and debugger are totally irrelevant to the point. I can use
a nice GUI to debug a fully compiliant program or a program that uses
extensions. The same for a debugger. An editor that runs in line
mode like Edlin is no more a part of the language than Eclipse is.

If you think that by adding threading to your compiler you have
enlarged the C language then you are simply incompetent. It means
that you do not understand the basic fundamentals of what you are
doing.

 

[user923005]

By the same argument,

requires an extension in some sense, because it is probably accomplished
using assembly.

No, it doesn't require an extension, because it can be interpreted by a
compiler accepting exactly the language as defined by the C standard.

The compiler can use any magic it likes to accomplish anything by any
manner. That's not an extension, as long as it is part of the language.

The definition of offsetof is required to become part of the language
accepted by the implementation, I believe.

It is highly likely that your compilers memcpy() is implemented in
assembly and not in C, because it may behave more efficiently given
certain conditions like alignments or object sizes. There's nothing
wrong with that and it is not an extension.

That depends on how memcpy is defined.

string.h:
// ...
void *memcpy(void *restrict, const void *restrict, size_t);
// ...

string.asm:
_memcpy:
# inefficient assembly implementation
jmp _memmove

In this case, no extension is required, since the assembly version of
memcpy is not read at all by the compiler.

[...]

Let's make a simple definition that everyone can agree on:

If it compiles on every ideal, conforming C compiler then it requires
only the C language.
If it fails to compile on any conforming C compiler then it requires an
extension.

Sure, this means

#include <stddef.h>
struct S {
int m;};

enum {
zero = offsetof(struct S, m)

};

does not make use of an extension. I can agree on that. But how is
offsetof defined? Let's say it is defined in <stddef.h> as

typedef char __char;
#define offsetof(s, m) ((__char *) &((s *) 0)->m - (__char *) (s *) 0)

Now, after expanding offsetof, it no longer compiles on every ideal,
conforming C compiler. In fact, it violates a constraint which would
cause at least one implementation to reject the program with a hard
error. So by your definition, this _implementation of_ offsetof does make
use of an extension, unless I'm misunderstanding your message.- Hide quoted text -

- Show quoted text -

If you expand your macro, so that the code does this, then you have
indeed violated the C language because that is very likely to fail.
#define offsetof(s, m) ((__char *) &((s *) 0)->m - (__char *) (s *) 0)

On the other hand, if you simply use the offsetof() macro and trust
your implementation to implement it as it should then there is no
violation of the standard (indeed, if you do it any other way then you
'have a screw loose').

Similarly,

i++;

may actually be implemented as:

_asm INC EAX;

which is not part of the C language, but why should I care? I am
responsible to write compliant code and the compiler is responsible to
translate it into machine instructions. Besides asking how does
offsetof() work, we may as well ask how malloc() works etc. Chances
are good that a large percentage of the actual internals of a compiler
require assembly language trickery. But any of that is neither here
nor there and is simply covered in the implementation details.
Whether they use assembly or library calls or a giant pile of
interpreted Lisp in the background isn't all that important. They can
accomplish the goal any way that they like, as long as it does what is
promised. I think that your major point is "A C compiler cannot be
accomplished strictly using C, because an extension is going to be
needed somewhere along the way." I don't think that anyone disagrees
with that (or if they do, the disagreement is not important). What is
important is that they accomplish the goals with whatever means are at
their disposal and that if I perform my part of the bargain (writing
correct C code) then they must also accomplish their part of the
bargain (correctly translating the C code as required by the
standard).

A conforming program should compile on any C compiler that claims to
conform. If it does not compile and the vendor claims to have a C
compiler then I have the right to complain and ask that the defect be
fixed. If the defect is not fixed in a timely manner then I have a
right to ask for my money back.

 

[Harald van Dijk]

If you expand your macro, so that the code does this, then you have
indeed violated the C language because that is very likely to fail.
#define offsetof(s, m) ((__char *) &((s *) 0)->m - (__char *) (s *) 0)

On the other hand, if you simply use the offsetof() macro and trust your
implementation to implement it as it should then there is no violation
of the standard (indeed, if you do it any other way then you 'have a
screw loose').

Right, but...

Similarly,

i++;

may actually be implemented as:

_asm INC EAX;

which is not part of the C language, but why should I care? I am
responsible to write compliant code and the compiler is responsible to
translate it into machine instructions. Besides asking how does
offsetof() work, we may as well ask how malloc() works etc.

[...]

....my point was that the definition of offsetof must be in a way that is
accepted by the C compiler, and the definition of i++ or the definition
of malloc don't need to be.

 

[Flash Gordon]

Harald van Dijk wrote, On 17/12/07 20:01:

To make sure I'm not misunderstanding, you're suggesting an
implementation might define

#define offsetof(s, m) __special__compiler__magic__offsetof__(s, m)

where __special__compiler__magic__offsetof__ is undocumented? If so, I
would consider that an extension. (And if it is an extension,
documentation is required.)

The implementation is allowed to do that. Having done that it is *not*
required to document __special_compiler_magic_offsetof__. So either you
have to accept that it is not an extension or you have to allow for
extensions that are not documented and could change on the next minor
release of the compiler or even if you change a compiler switch. Since
it could be
#ifdef __switch_1_set
#define offsetof(s,m) __magic1(s,m)
#else
#ifdef __switch_2_set
#define offsetof(s,m) __magic1(m,s)
#else
#define offsetof(s,m) __magic2(m,s)
#endif
#endif

Yes, I know the parameters are swapped, that was deliberate.

Further more stdlib.h might not be a file at all, it could all be
implemented by compiler magic as long as offsetof acts as if it is a
macro defined in stdlib.h

It's an extension even in the most literal
sense of the word -- it extends the language accepted by the
implementation -- and I'm not aware of any alternative definitions by
which it wouldn't be considered one. Could you please explain a bit more?

I would only consider it as an extension if it is documented as being
available for use.