Multi precision floating point

[user923005]

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,

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.

And my point is that it is irrelevant if part of the C compiler is
accomplished in C or with something else.

 

[Keith Thompson]

=?UTF-8?q?Harald_van_D=C4=B3k?= wrote:

[...]
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?

It's going to be difficult to resolve this question, since the
standard doesn't provide a rigorous definition of the word
"extension".

 

[jacob navia]

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.

I am "incompetent" as Hans J. Boehm:

"Threads cannot be implemented as Libraries"

http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf

Before insulting other people, read the literature, turn on your brain,
and then, discuss without getting emotional.

OK?

 

[user923005]

I am "incompetent" as Hans J. Boehm:

"Threads cannot be implemented as Libraries"

Non-sequiter. I have made no claims counter to what "Mr. Garbage
Collector" says.

http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf

I have read about garbage collection before. It does not belong in C
or C++, by the way.

Before insulting other people, read the literature, turn on your brain,
and then, discuss without getting emotional.

A great policy.

OK?

I agree that it is good advice, and I think you should follow it.

 

[Harald van Dijk]

And my point is that it is irrelevant if part of the C compiler is
accomplished in C or with something else.

You've demonstrated your point by comparing my example to a too
significantly different example, for reasons I've explained in the
message you replied to. It's possible you're right, but you do need some
argumentation to back it up if you want to convince me or others.

 

[Harald van Dijk]

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

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.

If it's an extension, it must be documented. The standard is quite
explicit about that (4p8). The only possibility is that it's not an
extension at all.

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

That's a good point, I forgot about that. On such an implementation, I
guess the question would be whether the compiler magic behind
#include <stddef.h>
is an extension, and I personally do not think it would be, since this is
a standard construct.

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

While I agree with that, I would conclude that this requires the
particular definition of offsetof to be documented.

However, since you've given a different example where we can both agree
there is no extension, I have to admit that it's possible to write a
conforming C implementation that does not have any extensions. I'm not
sure there exists such an implementation, but even if not, it's possible
someone will write one in the future.

 

[Harald van Dijk]

It's going to be difficult to resolve this question, since the standard
doesn't provide a rigorous definition of the word "extension".

Yes, that's unfortunate, and it's also unfortunate that the rationale
doesn't help explain.

 

[user923005]

You've demonstrated your point by comparing my example to a too
significantly different example, for reasons I've explained in the
message you replied to. It's possible you're right, but you do need some
argumentation to back it up if you want to convince me or others.

I retract my point that you cannot do offsetof() using standard C. I
was wrong about that.

Here is the relevant bit from the standard:
7.17 Common definitions <stddef.h>
1 The following types and macros are defined in the standard header
<stddef.h>. Some are also defined in other headers, as noted in their
respective subclauses.
2 The types are
ptrdiff_t
which is the signed integer type of the result of subtracting two
pointers;
size_t
which is the unsigned integer type of the result of the sizeof
operator; and
wchar_t
which is an integer type whose range of values can represent distinct
codes for all members of the largest extended character set specified
among the supported locales; the null character shall have the code
value zero and each member of the basic character set shall have a
code value equal to its value when used as the lone character in an
integer character constant.
3 The macros are
NULL
which expands to an implementation-defined null pointer constant; and
offsetof(type, member-designator)
which expands to an integer constant expression that has type size_t,
the value of which is the offset in bytes, to the structure member
(designated by member-designator), from the beginning of its structure
(designated by type). The type and member designator shall be such
that given static type t; then the expression &(t.member-designator)
evaluates to an address constant. (If the specified member is a bit-
field, the behavior is undefined.)
Forward references: localization (7.11).

Therefore, use of the offsetof() macro requires nothing whatsoever
beyond standard C.
Think about it, and you will see my point.

 

[jacob navia]

Non-sequiter. I have made no claims counter to what "Mr. Garbage
Collector" says.

Strange, I understood that you were against adding threads to the
language (i.e. within the compiler)

Or what then was your position?

It would be nice if you speak clearly then.

I understand that as you being against adding threads to the language
itself.

 

[user923005]

If it's an extension, it must be documented. The standard is quite
explicit about that (4p8). The only possibility is that it's not an
extension at all.








That's a good point, I forgot about that. On such an implementation, I
guess the question would be whether the compiler magic behind
#include <stddef.h>
is an extension, and I personally do not think it would be, since this is
a standard construct.



While I agree with that, I would conclude that this requires the
particular definition of offsetof to be documented.

However, since you've given a different example where we can both agree
there is no extension, I have to admit that it's possible to write a
conforming C implementation that does not have any extensions. I'm not
sure there exists such an implementation, but even if not, it's possible
someone will write one in the future.

I think that your definition of 'extensions' is broken.
If it is in the C standard, then *by definition* it is *NOT* an
extension.
The nuts and bolts of how it is achieved are irrelevant. It is part
of the language if it is in the standard.

 

[jacob navia]

Yes, that's unfortunate, and it's also unfortunate that the rationale
doesn't help explain.

Hey guys, the standard says:
<quote>
A conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any
strictly conforming
program.3)
<end quote>
So, anything that doesn't break the established rules is ALLOWED.

 

[user923005]

Strange, I understood that you were against adding threads to the
language (i.e. within the compiler)

Definintely a comprehension problem on your part. I suggested that
the C language does not define threads. I suggested that threads can
be supplied by an implementation.

Or what then was your position?

It would be nice if you speak clearly then.

My position is very clear to a clear thinker.

I understand that as you being against adding threads to the language
itself.

I do not know if it is a good idea to add threads to the language or
not. I will say that if threads are added to the language, then they
must be added by the standards committee. If an implementor adds
threads to the language then this does not extend the C language but
(rather) creates an extension to the C language.

Do you understand the difference between:
The language C with threads added to it.
(A vendor cannot do this, only the standards committee can.)

And
The C language extended by threads.
(A vendor can do this.)

?

By the way, I think that adding garbage collection to C would be a
terrible mistake. If that happens, then it will no longer be possible
to create reliable real time versions of the C language.

 

[user923005]

Hey guys, the standard says:
<quote>
A conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any
strictly conforming
program.3)
<end quote>
So, anything that doesn't break the established rules is ALLOWED.

I do not believe than anyone has ever argued this point.
However, I think that a diagnostic should be issued for a compiler
that does something like this:

qfloat foo = 12345678901234567890.9999999Q;

Failure to emit a diagnostic in conformant mode is an indication that
the compiler is broken.

 

[user923005]

From my own post upthread:

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

enum {
zero = offsetof(struct S, m)

};

does not make use of an extension."

Would you please start reading already, before replying again?

Do we agree (then) that use of offsetof() does not require a language
extension?
If so, then I do not understand what the issue is.

 

[pete]

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?

According to the output of putc.c,
putc('H', stdio)
looks like this in the translation unit on my C implementation:
(--(stdio)->_cnt >= 0 ? 0xff & (*(stdio)->_ptr++ = (char)('H')) :
_flsbuf(('H'),(stdio)))

It isn't portable C code and I don't see anything
that I would call an extension, in there.

/* BEGIN putc.c */

#include <stdio.h>

#define str(s) # s
#define xstr(s) str(s)

int main(void)
{
puts(xstr(putc('H', stdio)));
putchar('\n');
return 0;
}

/* END putc.c */

 

[user923005]

Whether the definition, as opposed to the use, of offsetof requires a
language extension.

In that case, the answer is clearly 'No' because the exact definition
of the offsetof() macro was provided by the quote that I have included
upstream. Therefore, the offsetof() macro does not require any
extensions.

One possibility to define it strictly with C is to use the FAQ
alternative:

2.14: How can I determine the byte offset of a field within a
structure?

A: ANSI C defines the offsetof() macro in <stddef.h>, which lets
you compute the offset of field f in struct s as
offsetof(struct s, f). If for some reason you have to code
this
sort of thing yourself, one possibility is

#define offsetof(type, f) ((size_t) \
((char *)&((type *)0)->f - (char *)(type *)0))

This implementation is not 100% portable; some compilers may
legitimately refuse to accept it.

References: ISO Sec. 7.1.6; Rationale Sec. 3.5.4.2; H&S
Sec. 11.1 pp. 292-3.

And then make it a language requirement to accept that construct.

In the message that started this subthread, I posted:
"offsetof is required to be defined in the standard headers, not merely
declared, and its definition requires extensions."

(As Flash Gordon pointed out, it turns out to be possible for a compiler
to accept
#include <stddef.h>
in a way that requires absolutely nothing of what I would consider
extensions, by using compiler magic for the #include statement itself.)- Hide quoted text -

- Show quoted text -

I guess that I simply do not understand the point of contention. I
really see no difficulty in the definition (in terms of C) because the
official document defines it, and so I see it as defined within the
language.

 

[Harald van Dijk]

According to the output of putc.c,
putc('H', stdio)
looks like this in the translation unit on my C implementation:
(--(stdio)->_cnt >= 0 ? 0xff & (*(stdio)->_ptr++ = (char)('H')) :
_flsbuf(('H'),(stdio)))

It isn't portable C code and I don't see anything that I would call an
extension, in there.

Agreed, that's not a language extension (although possibly a library
extension). It relies on what in standard C has undefined behaviour --
without syntax errors or constraint violations, so without a requirement
for a diagnostic -- for which the behaviour is not required to be
documented by the implementation.

/* BEGIN putc.c */

#include <stdio.h>

#define str(s) # s
#define xstr(s) str(s)

int main(void)
{
puts(xstr(putc('H', stdio)));
putchar('\n');
return 0;
}

/* END putc.c */

This is not a valid C program. To use two exteme examples,
implementations are reject the above program with a complaint about an
excessively long string literal, or they are allowed to define putc using
compiler extensions involving a backslash which does not start a valid
escape sequence. Stringizing standard library macros is a bad idea in
general.

 

[CBFalconer]

.... snip ...


I do not believe than anyone has ever argued this point.
However, I think that a diagnostic should be issued for a
compiler that does something like this:

qfloat foo = 12345678901234567890.9999999Q;

Failure to emit a diagnostic in conformant mode is an indication
that the compiler is broken.

I actually disagree, but at any rate a simple output of "This
compilation accepts non-standard gubris" will suffice. The
standard does not specify quality.

 

[pete]

Agreed, that's not a language extension (although possibly a library
extension). It relies on what in standard C has undefined behaviour --
without syntax errors or constraint violations,
so without a requirement
for a diagnostic -- for which the behaviour is not required to be
documented by the implementation.


This is not a valid C program.
To use two exteme examples,
implementations are reject the above program with a complaint about an
excessively long string literal,
or they are allowed to define putc using
compiler extensions involving a backslash which does not start a valid
escape sequence. Stringizing standard library macros is a bad idea in
general.

It is a "conforming program".

N869
4. Conformance
[#7] A conforming program is one that is acceptable to a
conforming implementation.

 

[Harald van Dijk]

In that case, the answer is clearly 'No' because the exact definition of
the offsetof() macro was provided by the quote that I have included
upstream. Therefore, the offsetof() macro does not require any
extensions.

You haven't provided a definition of the offsetof macro. You've told your
implementation to provide you with a definition of the offsetof macro.

One possibility to define it strictly with C is to use the FAQ
alternative:
[FAQ 2.14]
And then make it a language requirement to accept that construct.

That's actually essentially the definition I used upthread, but it
doesn't rely only on undefined behaviour, it also relies on the compiler
not rejecting a specific program with a constraint violation. Using that
definition, the expanded version of the above code is

struct S {
int m;
};

enum {
zero = ((char *) &((struct S *) 0)->m - (char *) (struct S *) 0)
};

which is a constraint violation, because the generated expression is not
an integral constant expression. And part of my argument was that if a
compiler accepts a program with a syntax error or a constraint violation,
it has used an extension. (I'm not sure on your position now, so I'm not
sure if you agree or disagree with that.)

I guess that I simply do not understand the point of contention. I
really see no difficulty in the definition (in terms of C) because the
official document defines it, and so I see it as defined within the
language.

Even if you consider the whole of standard C (including the standard
library) to be part of the language, I hope you can still agree the
language as accepted by the compiler (which essentially means grammar
+constraints+semantics) can't agree exactly with the grammar+constraints
+semantics as specified for the non-library portions of the C standard,
if offsetof is defined using #define in an ordinary file named stddef.h.