signed and unsigned ?
Jeremy Yallop
Dan Pop wrote:
> In <slrnauch0b...@saturn.cps.co.uk> Jeremy Yallop
> <jer...@jdyallop.freeserve.co.uk> writes:
>
>>Dan Pop wrote:
>>> In <slrnauc2a3...@saturn.cps.co.uk> Jeremy
>>> Yallop <jer...@jdyallop.freeserve.co.uk> writes:
>>>>
>>>>Create a string representing an out-of-range negative value and pass
>>>>it to strtol().
>>>
>>> How could I use this method to figure out the minimum value representable
>>> by ptrdiff_t or even int?
>>
>>I don't think that you can do it for ptrdiff_t.
I've changed my mind slightly on this. I think that it's possible for
ptrdiff_t if (and only if) it's possible for int.
>>For int, you know
>>that INT_MIN is either -INT_MAX or -INT_MAX - 1. Knowing LONG_MIN is
>>sufficient to determine which of these two values is the right one for
>>INT_MIN, AFAICS.
>
> ???
It looks like you're right. I had supposed that the standard requires
an implementation to use the same representation for all signed types
and that the values in <limits.h> are dictated by the representation
(for example, that an implementation with thirty-two bit two's
complement longs must have LONG_MIN equal to -2147483648LL). It seems
that the second of these assumptions was unwarranted. I'm not sure
about the first, but I think that it's the *intent* of 6.2.6.2
(integer types) even if it's not explicit.
>>I don't think that the standard allows INT_MIN to be
>>-32767 and LONG_MIN to be -2147483648, for example.
>
> Chapter and verse, please.
>
> AFAICT, even the pathological case with LONG_MIN == -2147483648LL and
> INT_MIN == -2147483647 is allowed by the standard.
I think you're probably right. Of course, such an implementation is
extremely unlikely, to say the least.
Jeremy.
James Kuyper Jr.
> [Crossposted to comp.std.c]
>
> Dan Pop wrote:
>
>>In <slrnauch0b...@saturn.cps.co.uk> Jeremy Yallop
>><jer...@jdyallop.freeserve.co.uk> writes:
>>
>>
>>>Dan Pop wrote:
>>>
>>>>In <slrnauc2a3...@saturn.cps.co.uk> Jeremy
>>>>Yallop <jer...@jdyallop.freeserve.co.uk> writes:
>>>>
>>>>>Create a string representing an out-of-range negative value and pass
>>>>>it to strtol().
I don't see enough context. Using LONG_MIN from <limits.h> would seem to
be a simpler solution to whatever problem that advice was meant to solve.
>>>>How could I use this method to figure out the minimum value representable
>>>>by ptrdiff_t or even int?
>>>
>>>I don't think that you can do it for ptrdiff_t.
I suppose if LONG_MIN wasn't an acceptable answer to the first problem,
then PTRDIFF_MIN, defined in <stdint.h>, wouldn't be an acceptable
answer to this one?
>>>For int, you know
>>>that INT_MIN is either -INT_MAX or -INT_MAX - 1. Knowing LONG_MIN is
>>>sufficient to determine which of these two values is the right one for
>>>INT_MIN, AFAICS.
>>
>>???
>
>
> It looks like you're right. I had supposed that the standard requires
> an implementation to use the same representation for all signed types
> and that the values in <limits.h> are dictated by the representation
> (for example, that an implementation with thirty-two bit two's
> complement longs must have LONG_MIN equal to -2147483648LL). It seems
> that the second of these assumptions was unwarranted. I'm not sure
> about the first, but I think that it's the *intent* of 6.2.6.2
> (integer types) even if it's not explicit.
For signed types, the standard says nothing that links the value of
TYPE_MIN to the value of TYPE_MAX. It'd quite legal to have INT_MIN of
-32767 and INT_MAX of 999999999.
>>>-32767 and LONG_MIN to be -2147483648, for example.
>>
>>Chapter and verse, please.
>>
>>AFAICT, even the pathological case with LONG_MIN == -2147483648LL and
>>INT_MIN == -2147483647 is allowed by the standard.
>
>
> I think you're probably right. ...
He is.
Jun Woong
news:3DE98856...@wizard.net...
> Jeremy Yallop wrote:
> > [Crossposted to comp.std.c]
> >
> > Dan Pop wrote:
> >
> >>In <slrnauch0b...@saturn.cps.co.uk> Jeremy Yallop
> >><jer...@jdyallop.freeserve.co.uk> writes:
> >>
> >>
> >>>Dan Pop wrote:
> >>>
> >>>>In <slrnauc2a3...@saturn.cps.co.uk> Jeremy
> >>>>Yallop <jer...@jdyallop.freeserve.co.uk> writes:
> >>>>
> >>>>>Create a string representing an out-of-range negative value and pass
> >>>>>it to strtol().
>
> I don't see enough context. Using LONG_MIN from <limits.h> would seem to
> be a simpler solution to whatever problem that advice was meant to solve.
>
> >>>>How could I use this method to figure out the minimum value
representable
> >>>>by ptrdiff_t or even int?
> >>>
> >>>I don't think that you can do it for ptrdiff_t.
>
> I suppose if LONG_MIN wasn't an acceptable answer to the first problem,
> then PTRDIFF_MIN, defined in <stdint.h>, wouldn't be an acceptable
> answer to this one?
I guess that he is saying about C90 where <stdint.h> is not available.
>
> >>>For int, you know
> >>>that INT_MIN is either -INT_MAX or -INT_MAX - 1. Knowing LONG_MIN is
> >>>sufficient to determine which of these two values is the right one for
> >>>INT_MIN, AFAICS.
> >>
> >>???
> >
> > It looks like you're right. I had supposed that the standard requires
> > an implementation to use the same representation for all signed types
> > and that the values in <limits.h> are dictated by the representation
> > (for example, that an implementation with thirty-two bit two's
> > complement longs must have LONG_MIN equal to -2147483648LL). It seems
> > that the second of these assumptions was unwarranted. I'm not sure
> > about the first, but I think that it's the *intent* of 6.2.6.2
> > (integer types) even if it's not explicit.
>
> For signed types, the standard says nothing that links the value of
> TYPE_MIN to the value of TYPE_MAX. It'd quite legal to have INT_MIN of
> -32767 and INT_MAX of 999999999.
I don't think so. IIRC, IMT_MAX + INT_MIN has to be 0 or -1. There was
a C90 DR for this problem and I think it still applies.
--
Jun, Woong (myco...@hanmail.net)
Dept. of Physics, Univ. of Seoul
Kevin Easton
It's actually explicitly stated in C99 6.2.6.2:
1 For unsigned integer types other than unsigned char, the bits of the
object representation shall be divided into two groups: value bits and
padding bits (there need not be any of the latter). If there are N value
bits, each bit shall represent a different power of 2 between 1 and
2N-1, so that objects of that type shall be capable of representing
values from 0 to 2N - 1 using a pure binary representation; this shall
be known as the value representation. The values of any padding bits are
unspecified.39)
2 For signed integer types, the bits of the object representation shall
be divided into three groups: value bits, padding bits, and the sign
bit. There need not be any padding bits; there shall be exactly one sign
bit. Each bit that is a value bit shall have the same value as the same
bit in the object representation of the corresponding unsigned type (if
there are M value bits in the signed type
and N in the unsigned type, then M ? N). If the sign bit is zero, it
shall not affect the resulting value. If the sign bit is one, then the
value shall be modified in one of the following ways:
-- the corresponding value with sign bit 0 is negated;
-- the sign bit has the value -2N ;
-- the sign bit has the value 1 - 2N .
I think this means that you could theoretically write code that compared
the representations of a small set of values (say, -3, -1, 1, 3) to
determine which of these was in use, and therefore predict the minimum
value of the type.
- Kevin.
Jun Woong
news:ascdng$as8$1...@tomato.pcug.org.au...[...]
> >
> > I don't think so. IIRC, IMT_MAX + INT_MIN has to be 0 or -1. There was
> > a C90 DR for this problem and I think it still applies.
>
> It's actually explicitly stated in C99 6.2.6.2:
>
>
> I think this means that you could theoretically write code that compared
> the representations of a small set of values (say, -3, -1, 1, 3) to
> determine which of these was in use, and therefore predict the minimum
> value of the type.
Only when there is no padding bits that can have arbitrary patterns.
James Kuyper Jr.
> "James Kuyper Jr." <kuy...@wizard.net> wrote in message
> news:3DE98856...@wizard.net...
>>I suppose if LONG_MIN wasn't an acceptable answer to the first problem,
>>then PTRDIFF_MIN, defined in <stdint.h>, wouldn't be an acceptable
>>answer to this one?
>
>
> I guess that he is saying about C90 where <stdint.h> is not available.
I would guess that too, but an explicit statement to that effect is
desirable. The default assumption for messages on this newsgroup should
be that we're discussing the current standard, not the old one.
...
>>For signed types, the standard says nothing that links the value of
>>TYPE_MIN to the value of TYPE_MAX. It'd quite legal to have INT_MIN of
>>-32767 and INT_MAX of 999999999.
>
>
> I don't think so. IIRC, IMT_MAX + INT_MIN has to be 0 or -1. There was
> a C90 DR for this problem and I think it still applies.
No. The concept of trap representations is new with C99, and modifies
the context from which that old DR was derived. An implementation is now
free to identify all bit patterns which would, in a conventional 32 bit
format, represent values greater than 999999999, to be trap representations.
James Kuyper Jr.
> In comp.lang.c Jun Woong <myco...@hanmail.net> wrote:
>
>>"James Kuyper Jr." <kuy...@wizard.net> wrote in message
>>news:3DE98856...@wizard.net...
6.2.6.2p1 specifies the upper and lower limits for unsigned types
precisely in terms of their number of bits. However, the next paragraph,
which describes signed types, does not. Therefore, the only limits on
the ranges of signed types are those given in 5.2.4.2.1p1 and the following:
6.2.5p8:
SCHAR_MIN>=SHORT_MIN>=INT_MIN>=LONG_MIN>=LLONG_MIN
SCHAR_MAX<=SHORT_MAX<=INT_MAX<=LONG_MAX<=LLONG_MAX
6.2.5p9:
SCHAR_MAX<=UCHAR_MAX
SHORT_MAX<=USHORT_MAX
INT_MAX<=UINT_MAX
LONG_MAX<=ULONG_MAX
LLONG_MAX<=ULLONG_MAX
Any values for the ranges of signed types that meet these requirements
and will fit within the size of the object are legal. All an
implementation has to do to implement arbitrary limits is to declare any
bit pattern for a given type, that would otherwise represent a value
larger than TYPE_MAX, or smaller than TYPE_MIN, to be a trap representation.
Peter Nilsson
...
> > I don't think so. IIRC, IMT_MAX + INT_MIN has to be 0 or -1. There was
> > a C90 DR for this problem and I think it still applies.
>
> No. The concept of trap representations is new with C99, and modifies
> the context from which that old DR was derived. An implementation is now
> free to identify all bit patterns which would, in a conventional 32 bit
> format, represent values greater than 999999999, to be trap representations.
Are you seriously telling me that for non-negative a and b:
a <= INT_MAX and b <= INT_MAX does NOT imply (a|b) is well defined?
What hope does a C program have!
--
Peter
Jun Woong
> Jun Woong wrote:
> > "James Kuyper Jr." <kuy...@wizard.net> wrote in message
> > news:3DE98856...@wizard.net...
> ...
> >>I suppose if LONG_MIN wasn't an acceptable answer to the first problem,
> >>then PTRDIFF_MIN, defined in <stdint.h>, wouldn't be an acceptable
> >>answer to this one?
> >
> >
> > I guess that he is saying about C90 where <stdint.h> is not available.
>
> I would guess that too, but an explicit statement to that effect is
> desirable. The default assumption for messages on this newsgroup should
> be that we're discussing the current standard, not the old one.
>
> ...
> >>For signed types, the standard says nothing that links the value of
> >>TYPE_MIN to the value of TYPE_MAX. It'd quite legal to have INT_MIN of
> >>-32767 and INT_MAX of 999999999.
> >
> >
> > I don't think so. IIRC, IMT_MAX + INT_MIN has to be 0 or -1. There was
> > a C90 DR for this problem and I think it still applies.
>
> No. The concept of trap representations is new with C99, and modifies
> the context from which that old DR was derived.
AFAICK, C99's new representation model for integer types are basically
derived from the DR.
> An implementation is now
> free to identify all bit patterns which would, in a conventional 32 bit
> format, represent values greater than 999999999, to be trap
representations.
>
Could you elaborate on this? I think I'm missing something here.
Padding bits (if any) which affect the trap representation don't
contribute to the value and the Standard prohibits sign bits more than
two.
James Kuyper Jr.
Yes, that's one implication.
> What hope does a C program have!
Restrict the portability of your code to implementations that don't take
advantage of this possibility (which isn't much of a restriction; I've
never heard of any), or restrict your bitwise operations to unsigned
types. The latter option is a good idea in general, and not just for
this reason.
James Kuyper Jr.
...
>>An implementation is now
>>free to identify all bit patterns which would, in a conventional 32 bit
>>format, represent values greater than 999999999, to be trap
>
> representations.
>
>
> Could you elaborate on this? I think I'm missing something here.
>
> Padding bits (if any) which affect the trap representation don't
> contribute to the value and the Standard prohibits sign bits more than
> two.
I'll grant you; INT_MIN of -32767 and INT_MAX of 999999999, with
sizeof(int)*CHAR_BIT==32, would imply that there's one padding bit.
However, I'm not specifically talking about padding bits. Change INT_MAX
to 1999999999, to avoid that complication.
I'm talking about bits which do contribute to the representation of
certain values, but which make certain other representations constitute
trap representations. The prototypical example of a trap representation,
the only integral one explicitly described by the standard, is the case
where a negative zero is treated as a trap. None of the bits that are
used to identify a negative zero is a padding bit.
Jeremy Yallop
> Jeremy Yallop wrote:
>> [Crossposted to comp.std.c]
>>
>> Dan Pop wrote:
>>>In <slrnauch0b...@saturn.cps.co.uk> Jeremy Yallop
>>><jer...@jdyallop.freeserve.co.uk> writes:
>>>>Dan Pop wrote:
>>>>>In <slrnauc2a3...@saturn.cps.co.uk> Jeremy
>>>>>Yallop <jer...@jdyallop.freeserve.co.uk> writes:
>>>>>
>>>>>>Create a string representing an out-of-range negative value and pass
>>>>>>it to strtol().
>
> I don't see enough context. Using LONG_MIN from <limits.h> would seem to
> be a simpler solution to whatever problem that advice was meant to solve.
Sorry for the lack of context. We were discussing the cases in which
it's possible to work out the range of a given (integer) type. It's
trivial for unsigned types, of course; someone mentioned that it's
possible for signed long (which was questioned, hence my words above);
the final question is whether it's possible to work out the range of a
signed integer type in general. Apparently it is not. (<limits.h> is
banned for the purpose of the exercise, but it wouldn't help with most
opaque types anyway).
> For signed types, the standard says nothing that links the value of
> TYPE_MIN to the value of TYPE_MAX. It'd quite legal to have INT_MIN of
> -32767 and INT_MAX of 999999999.
Thanks. I hadn't realised how few restrictions there actually are.
Is there any good reason not to stipulate a range of either
[-(2^n), (2^n)-1] or [-(2^n) + 1, (2^n)-1] for signed integer types?
(^ is exponentiation, not bitwise-or.) Are there any implementations
where signed integer types don't have such a range?
Jeremy.
Dan Pop
>2 For signed integer types, the bits of the object representation shall
>be divided into three groups: value bits, padding bits, and the sign
>bit. There need not be any padding bits; there shall be exactly one sign
>bit. Each bit that is a value bit shall have the same value as the same
>bit in the object representation of the corresponding unsigned type (if
>there are M value bits in the signed type
>and N in the unsigned type, then M ? N). If the sign bit is zero, it
>shall not affect the resulting value. If the sign bit is one, then the
>value shall be modified in one of the following ways:
>
> -- the corresponding value with sign bit 0 is negated;
> -- the sign bit has the value -2N ;
> -- the sign bit has the value 1 - 2N .
>
>I think this means that you could theoretically write code that compared
>the representations of a small set of values (say, -3, -1, 1, 3) to
>determine which of these was in use, and therefore predict the minimum
>value of the type.
It's not that easy: you can't tell which is a value bit and which is a
padding bit. Even worse, the standard allows a two's complement
implementation to treat -TYPE_MAX - 1 as a trap representation:
Which of these applies is implementation-defined, as is
whether the value with sign bit 1 and all value bits zero
(for the first two), or with sign bit and all value bits 1 (for
one's complement), is a trap representation or a normal value.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Dan Pop
>Jun Woong wrote:
>> "James Kuyper Jr." <kuy...@wizard.net> wrote in message
>> news:3DE98856...@wizard.net...
>...
>>>For signed types, the standard says nothing that links the value of
>>>TYPE_MIN to the value of TYPE_MAX. It'd quite legal to have INT_MIN of
>>>-32767 and INT_MAX of 999999999.
Nope, it won't: C99 guarantees that:
1. TYPE_MAX is one less than a power of two
2. TYPE_MIN is either -TYPE_MAX or -TYPE_MAX - 1.
>> I don't think so. IIRC, IMT_MAX + INT_MIN has to be 0 or -1. There was
>> a C90 DR for this problem and I think it still applies.
>
>No. The concept of trap representations is new with C99, and modifies
>the context from which that old DR was derived. An implementation is now
>free to identify all bit patterns which would, in a conventional 32 bit
>format, represent values greater than 999999999, to be trap representations.
Nope, it ain't.
6.2.6.2 Integer types
1 For unsigned integer types other than unsigned char, the bits
of the object representation shall be divided into two groups:
value bits and padding bits (there need not be any of the
latter). If there are N value bits, each bit shall represent
a different power of 2 between 1 and 2**(N-1), so that objects of
that type shall be capable of representing values from 0 to 2**N - 1
using a pure binary representation; this shall be known as
the value representation. The values of any padding bits are
unspecified.44)
2 For signed integer types, the bits of the object representation
shall be divided into three groups: value bits, padding bits,
and the sign bit. There need not be any padding bits; there shall
be exactly one sign bit. Each bit that is a value bit shall have
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the same value as the same bit in the object representation
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
of the corresponding unsigned type (if there are M value bits
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
in the signed type and N in the unsigned type, then M <= N).
If the sign bit is zero, it shall not affect the resulting value.
If the sign bit is one, the value shall be modified in one of
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the following ways:
^^^^^^^^^^^^^^^^^^
- the corresponding value with sign bit 0 is negated (sign
and magnitude);
- the sign bit has the value -(2**N) (two's complement);
- the sign bit has the value -(2**N - 1) (one's complement).
Which of these applies is implementation-defined, as is
whether the value with sign bit 1 and all value bits zero
(for the first two), or with sign bit and all value bits 1 (for
one's complement), is a trap representation or a normal value.
Pay special attention to the underlined statements.
The only trap representations involving the sign and value bits allowed
are documented at the end of the quoted text.
Dan Pop
>James Kuyper Jr. wrote:
>
>> For signed types, the standard says nothing that links the value of
>> TYPE_MIN to the value of TYPE_MAX. It'd quite legal to have INT_MIN of
>> -32767 and INT_MAX of 999999999.
>
>Thanks. I hadn't realised how few restrictions there actually are.
>Is there any good reason not to stipulate a range of either
>[-(2^n), (2^n)-1] or [-(2^n) + 1, (2^n)-1] for signed integer types?
The standard effectively stipulates one of these two ranges. The only
quirk is that even a two's complement representation can have the
latter range (the bit pattern that would represent -(2^n) is allowed
to be a trap representation).
>(^ is exponentiation, not bitwise-or.) Are there any implementations
>where signed integer types don't have such a range?
There is (historical) hardware that couldn't implement such ranges in
an efficient manner (BCD machines), but the C standard is friendly only
to purely binary hardware, only.
James Kuyper Jr.
> In <3DEA2984...@wizard.net> "James Kuyper Jr." <kuy...@wizard.net> writes:
>
>
>>Jun Woong wrote:
>>
>>>"James Kuyper Jr." <kuy...@wizard.net> wrote in message
>>>news:3DE98856...@wizard.net...
>>
>>...
>>
>>>>For signed types, the standard says nothing that links the value of
>>>>TYPE_MIN to the value of TYPE_MAX. It'd quite legal to have INT_MIN of
>>>>-32767 and INT_MAX of 999999999.
>>>
>
> Nope, it won't: C99 guarantees that:
>
> 1. TYPE_MAX is one less than a power of two
>
> 2. TYPE_MIN is either -TYPE_MAX or -TYPE_MAX - 1.
Citation, please? I can find such guarantees only for unsigned types. It
does not follow from the clauses you've cited below.
And the implementation I've described does not violate those
requirements. In every non-trap representation, those bits do indeed
have the value required by the underlined statements.
> The only trap representations involving the sign and value bits allowed
> are documented at the end of the quoted text.
There's nothing which indicates that those are the only trap
representations allowed.
The standard treats those representations in a special manner, because 0
is the only value that can have two different representations under
those rules. The purpose of that paragraph is to indicate that an
implementation is free to NOT support both representations.
If the intent was also to specify that this is the only integral trap
representation involving sign and value bits that is allowed, then it
fails to be sufficiently specific to make that clear.
Douglas A. Gwyn
> There's nothing which indicates that those are the only trap
> representations allowed.
The allowed integer representations are for the value&sign bits
to be used *only* as ones-complement, sign-magnitude, or twos-
complement. The "minus zero" in the first two schemes can be
one of the trap representations although it doesn't have to be.
Other trap representations involve the padding bits.
Dan Pop
Your implementation arbitrarily fails to attribute the value *required*
by the standard to certain representations. It, therefore, does
violate the underlined statements.
>> The only trap representations involving the sign and value bits allowed
>> are documented at the end of the quoted text.
>
>There's nothing which indicates that those are the only trap
>representations allowed.
There's nothing allowing *other* trap representations, as far as only
the sign and value bits are concerned. Your postulation that such
trap representations are allowed has zilch support in the text of the
standard (unless you can provide a quote that is relevant, in context).
>The standard treats those representations in a special manner, because 0
>is the only value that can have two different representations under
>those rules. The purpose of that paragraph is to indicate that an
>implementation is free to NOT support both representations.
You didn't pay attention: in two's complement case, there is no alternate
representation for 0, but there is -(2**N) that could be either TYPE_MIN
or a trap representation.
>If the intent was also to specify that this is the only integral trap
>representation involving sign and value bits that is allowed, then it
>fails to be sufficiently specific to make that clear.
The lack of any other specification for such trap representations,
combined with the underlined statements, makes it quite clear.
Peter Nilsson
The impact goes beyond mere bitwise operators. The interpretation
would mean that a strictly conforming program would virtually have to
rule out division involving a positive dividend and *any* negative
divisor.
And there /are/ programs in existance which naturally assume that you
can divide by negative numbers other than -1 on twos complement
machines.
--
Peter
James Kuyper Jr.
>>And the implementation I've described does not violate those
>>requirements. In every non-trap representation, those bits do indeed
>>have the value required by the underlined statements.
>
>
> Your implementation arbitrarily fails to attribute the value *required*
> by the standard to certain representations. It, therefore, does
> violate the underlined statements.
That's covered by 6.2.6.1p5 - any code which could otherwise demonstrate
that problem, has undefined behavior, since the implementation has made
use of it's freedom to identify those representations as trap
representations.
>>>The only trap representations involving the sign and value bits allowed
>>>are documented at the end of the quoted text.
>>
>>There's nothing which indicates that those are the only trap
>>representations allowed.
>
>
> There's nothing allowing *other* trap representations, as far as only
> the sign and value bits are concerned. Your postulation that such
6.2.6.1p5 is what allows those representations to be identified as trap
representations. There's nothing in the standard restricting trap
representations for integer types to using the padding bits. There are
definitions of the sign and value bits, but those definitions are
completely satisfied even if there's only one non-trap representation in
which they have a non-zero value.
>>The standard treats those representations in a special manner, because 0
>>is the only value that can have two different representations under
>>those rules. The purpose of that paragraph is to indicate that an
>>implementation is free to NOT support both representations.
>
>
> You didn't pay attention: in two's complement case, there is no alternate
> representation for 0, but there is -(2**N) that could be either TYPE_MIN
> or a trap representation.
You're right, but that doesn't affect my main point. That point was that
this clause makes it clear that some trap representations can be
identified using only sign and value bits, and does not explicitly limit
the set of such trap representations to the ones identified in that clause.
>>If the intent was also to specify that this is the only integral trap
>>representation involving sign and value bits that is allowed, then it
>>fails to be sufficiently specific to make that clear.
>
>
> The lack of any other specification for such trap representations,
The lack of any other applicable restrictions on trap representations
must also be taken into account.
Dan Pop
A more general paragraph, 6.2.6.1p5, cannot override a more specific one,
6.2.6.2p2, which specifies the possible interpretations of any given
representation (as far as only sign and value bits are involved).
Jim Balter
Unfortunately, the standard did not also provide a means to determine
the min and max values of arbitrary types. As a consequence, it
is now necessary to accompany every integer typedef with the corresponding
constants in order to write truly portable code.
There's a fundamental failure in the standards process that has
resulted in large but unnecessary (other than job security) efforts
to achieve portability. (By portability here I mean it in the
sense of portability across architectures -- of writing strictly conforming
code -- not in the sense of portability to C89, K&R, BCPL, or other
ancient and obsolete systems that don't conform to the latest
C language standard.) The process is that people find ways to
deal with failures of the language to provide necessary support,
by creating header files filled with all sorts of gross stuff.
Other people trying to solve the same problems adopt these
header files, vendors provide them, and they become "common practice".
The standard committees then standardize them, *without rectifying
the original failure that made them necessary*. No competent language
designer would decide that the best way to allow users to
determine the min and max values for various types would be to define
a bunch of explicit symbols for a fixed set of types -- yet that is the
language we now have. The committee could have fixed this by requiring
that compilers make visible to the user such information -- a quite
trivial thing to implement. I believe this would have happened if the
standards committee was actually committed to the C language user community,
rather than the C compiler vendors and C language lawyers communities
(the latter folks have gotten so used to employing their deep knowledge
of the language to find arbitrarily clever and arcane solutions
that they often lose track of the fact that that's not actually the end
goal; of course this problem isn't limited to C -- consider how proud
people are of their shell hacks when they should be embarrassed to be
using the wrong tool).
--
<J Q B>
James Kuyper Jr.
...
> It looks like you're right. I had supposed that the standard requires
> an implementation to use the same representation for all signed types
It most definitely does not.
> and that the values in <limits.h> are dictated by the representation
> (for example, that an implementation with thirty-two bit two's
> complement longs must have LONG_MIN equal to -2147483648LL). It seems
> that the second of these assumptions was unwarranted. I'm not sure
> about the first, but I think that it's the *intent* of 6.2.6.2
> (integer types) even if it's not explicit.
I doubt that; but I wasn't there, so I can't be sure.
P.J. Plauger
news:3E056017...@cW.comdiespammersdie...
> No competent language
> designer would decide that the best way to allow users to
> determine the min and max values for various types would be to define
> a bunch of explicit symbols for a fixed set of types -- yet that is the
> language we now have.
So Dennis Ritchie is incompetent? 'Nuf said.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jim Balter
> "Jim Balter" <Jim.B...@cW.comdiespammersdie> wrote in message
> news:3E056017...@cW.comdiespammersdie...
>
>
>> No competent language
>>designer would decide that the best way to allow users to
>>determine the min and max values for various types would be to define
>>a bunch of explicit symbols for a fixed set of types -- yet that is the
>>language we now have.
>
>
> So Dennis Ritchie is incompetent? 'Nuf said.
Ritchie never made any such decision. And were he choosing
a path for the language now, I doubt that he would make such a
decision, for the very reasons I laid out, reasons that you have
provided no reasoned response to.
--
<J Q B>
James Kuyper Jr.
...
> There's a fundamental failure in the standards process that has
> resulted in large but unnecessary (other than job security) efforts
Job security is seldom a significant motive for people who have to pay
hefty annual membership fees for the privilege of volunteering to do the
work.
...
> trivial thing to implement. I believe this would have happened if the
> standards committee was actually committed to the C language user
> community,
> rather than the C compiler vendors and C language lawyers communities
You're making the assumption that the committee is dominated by compiler
vendors. There are lots of people on the committee who don't represent
any compiler vendor. The committee is heavily influenced by the vendors,
but then would you really expect a useable language standard to be
created entirely without vendor input?
Douglas A. Gwyn
> There's a fundamental failure in the standards process ...
You don't know what you're talking about.
It is easy to criticize others' work when you didn't
lend a hand.
Jim Balter
First, your response is non-substantive. Second, I *did*
lend a hand -- in 1987, after a discussion on BIX about
some issues in the language, one of the respondents
there told me that there was soom going to be a meeting
of the language committee, and facetiously suggested that
if I really cared so much I would discuss it there.
That was on a Thu or Fri and the meeting was Mon;
I tried to get a ticket but the prices to get there
by Monday were exhorbitant, so I very disappointedly
bought a ticket with my own money and flew from L.A. to
the east coast and purchased a membership in X3J11
with my own money, and was immediately put to work
in one of several small groups handling review comments,
which work I did my best to perform in an objective and
professional manner. And I was even more disappointed
to learn about "Monday papers" that were accepted from
committee members if they were presented on Monday --
but Tuesday was too late. I had a 30 page paper noting
numerous issues with the draft. Despite the lateness,
someone graciously offered to look at it, but it became
too much extra work, so I agreed to withdraw it -- I respected
the committee and how hard people were working and had no
desire to impose burdens, only to help. I did
ask that one formal flaw in the draft that had to do with
declarations in structs not being in a block be addressed,
and after Bill Plauger cleverly referred to it as
"a hubcap on a fiat", a change was accepted by the committee.
I flew again, on my own time and money, to the next meeting,
which turned out to be for the final vote. And when my
turn came, as the first to vote, despite numerous misgivings
about the draft as it stood, I knew that it certainly wasn't
my place, as a newcomer who had done far less than any of the
other people in the room, to make any sort of statement
with a "no" vote. You might contrast that with the fellow
who held up the standard for a year because of his absurd
challenge due his paper having slipped between the cracks.
So enough with the ad hominems and the misrepresentations.
My comment is about the *process* and its consequences.
I don't know how the problems with the process might be
addressed, and I'm not asserting that, if I were on the
committee, things would have been better, but the problems
do exist and I have every right and reason to point them out,
for objective consideration and comment.
--
<J Q B>
Jim Balter
> Jim Balter wrote:
> ...
>
>> There's a fundamental failure in the standards process that has
>> resulted in large but unnecessary (other than job security) efforts
>
>
> Job security is seldom a significant motive for people who have to pay
> hefty annual membership fees for the privilege of volunteering to do the
> work.
I wasn't referring to the committee members; I meant folks who spend
a great deal of their lives making C code portable because of
lack of support in the language -- lack of such things as
minof(type) and maxof(type) and GNU's typeof(type) -- the latter
having been in use long before even C89 and yet still not
part of the language standard. I believe that indicates that
the committee sometimes loses track of what it's job is.
> ...
>
>> trivial thing to implement. I believe this would have happened if the
>> standards committee was actually committed to the C language user
>> community,
>> rather than the C compiler vendors and C language lawyers communities
>
>
> You're making the assumption that the committee is dominated by compiler
> vendors.
I didn't make any such assumption -- I stated what I believe to
be the case based on the evidence. And part of that evidence is
the very "hefty annual membership fees" and the amount of volunteer
work involved. It's only NATURAL that the committee would be
dominated by the vendor AND language lawyer communitees. What
random joe programmer would join the committee? I did back in '87,
but there were very few like me.
> There are lots of people on the committee who don't represent
> any compiler vendor. The committee is heavily influenced by the vendors,
> but then would you really expect a useable language standard to be
> created entirely without vendor input?
Why such strawmen and red herrings? I said nothing about not wanting
any vendor input. SHEESH.
--
<J Q B>
Francis Glassborow
<Jim.B...@cW.comdiespammersdie> writes
>So enough with the ad hominems and the misrepresentations.
>My comment is about the *process* and its consequences.
>I don't know how the problems with the process might be
>addressed, and I'm not asserting that, if I were on the
>committee, things would have been better, but the problems
>do exist and I have every right and reason to point them out,
>for objective consideration and comment.
But your actual experience of the Committee seems to date to an atypical
couple of meetings of J16. For a decade the C Standard has been handled
by WG14. My experience over that decade has been very different (and I
also, more often than not, fund myself even though I make no money from
any aspect of C)
The fundamental problem is that the WG14 can only address issues where
it has one or more available experts. For example you raised the issue
of 'typeof'. Putting aside the issue of its utility in C (I have no
doubt that it is useful in C++, and WG21 is addressing that issue for
the next C++ standard) as far as I know there is no one currently active
on WG14 who felt they understood the implications of typeof sufficiently
well to propose its adoption. Note that just because an extension works
well in a specific environment does not mean that it can simply be
adopted for all.
--
ACCU Spring Conference 2003 April 2-5
Check the details: http://www.accuconference.co.uk/
The Conference you cannot afford to miss
Francis Glassborow ACCU
Douglas A. Gwyn
> ... as far as I know there is no one currently active
> on WG14 who felt they understood the implications of
> typeof sufficiently well to propose its adoption.
I wouldn't say that it isn't well enough understood;
rather, its utility is seen as quite limited (for C)
and not worth the cost. The main utility for C would
be in the definition of some function-like macros
such as #define swap(a,b) {typeof(a)t=a;a=b;b=t;}
which hardly seems to justify the invention.
Gabriel Dos Reis
That is *one* view.
Here is another. C99 defines type-generic macros in <tgmath.h>,
practically portably unimplementable with just core Standard C
facilities. Moreover, it provides *no* way for the programmer to
defines its own type-generic macros. I find those serious
flaws. Introducing typeof() in C would repari most of them.
-- Gaby
Francis Glassborow
Reis <g...@integrable-solutions.net> writes
>That is *one* view.
>
>Here is another. C99 defines type-generic macros in <tgmath.h>,
>practically portably unimplementable with just core Standard C
>facilities. Moreover, it provides *no* way for the programmer to
>defines its own type-generic macros. I find those serious
>flaws. Introducing typeof() in C would repari most of them.
Thanks for pointing that out. I had completely missed seeing typeof as a
solution to my resentment that the C Standard abrogates to itself
generic facilities that it denies to me as a programmer.
Of course it may be that C programmers are not ready for any form of
genericity :-)
--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow ACCU
rjh
> In message <m3n0mwv...@uniton.integrable-solutions.net>, Gabriel Dos
> Reis <g...@integrable-solutions.net> writes
>>That is *one* view.
>>
>>Here is another. C99 defines type-generic macros in <tgmath.h>,
>>practically portably unimplementable with just core Standard C
>>facilities. Moreover, it provides *no* way for the programmer to
>>defines its own type-generic macros. I find those serious
>>flaws. Introducing typeof() in C would repari most of them.
>
> Thanks for pointing that out. I had completely missed seeing typeof as a
> solution to my resentment that the C Standard abrogates to itself
> generic facilities that it denies to me as a programmer.
One easy solution to this would have been to drop the type-generic macros. I
guess it's too late now.
> Of course it may be that C programmers are not ready for any form of
> genericity :-)
Or perhaps it's just that C programmers know where to find C++ if they want
it. In my not-as-humble-as-it-should-be opinion, C's strength lies in its
simplicity. C99 fixed one or two problems with C, but also introduced a
whole swathe of unnecessary complexities. It appears to be another of
life's givens: Death, taxes, and language evolution. Thing is, though - did
C really /need/ to be given that extra leg?
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Gabriel Dos Reis
| > Of course it may be that C programmers are not ready for any form of
| > genericity :-)
|
| Or perhaps it's just that C programmers know where to find C++ if they want
| it.
One rarely needs only One True Paradigm in daily programming tasks;
the fact that the language mandates some type-generic macros is, IMO,
an indication that some controlled form of static generecity is useful
in C programs.
Saying "C programmers know where to find C++ if they want it" when
some type-generic macros would ease tasks misses the point, IMNHO.
| In my not-as-humble-as-it-should-be opinion, C's strength lies in its
| simplicity.
What is so complicated about typeof()?
I find the semantics of typeof() are even simpler and more precise
than that of volatile. ;-)
-- Gaby
Brian Inglis
<g...@integrable-solutions.net> wrote:
Should it be able to take functions as well as objects?
Should it be able to have more than one argument?
How else does one create generics of functions with more than one
arg, like atan2()?
Other issues arise when you start looking at standards, depending
on the variety of existing implementations and applications of a
language feature.
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
Brian....@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
ab...@aol.com tos...@aol.com ab...@att.com ab...@earthlink.com
ab...@hotmail.com ab...@mci.com ab...@msn.com ab...@sprint.com
ab...@yahoo.com ab...@cadvision.com ab...@shaw.ca ab...@telus.com
ab...@ibsystems.com u...@ftc.gov spam traps
Gabriel Dos Reis
| On 24 Dec 2002 09:13:47 +0100, Gabriel Dos Reis
| <g...@integrable-solutions.net> wrote:
|
| >rjh <bin...@eton.powernet.co.uk> writes:
| >
| >| > Of course it may be that C programmers are not ready for any form of
| >| > genericity :-)
| >|
| >| Or perhaps it's just that C programmers know where to find C++ if they want
| >| it.
| >
| >One rarely needs only One True Paradigm in daily programming tasks;
| >the fact that the language mandates some type-generic macros is, IMO,
| >an indication that some controlled form of static generecity is useful
| >in C programs.
| >
| >Saying "C programmers know where to find C++ if they want it" when
| >some type-generic macros would ease tasks misses the point, IMNHO.
| >
| >| In my not-as-humble-as-it-should-be opinion, C's strength lies in its
| >| simplicity.
| >
| >What is so complicated about typeof()?
| >
| >I find the semantics of typeof() are even simpler and more precise
| >than that of volatile. ;-)
|
| Should it be able to take functions as well as objects?
Is there any reason to prohibit that?
| Should it be able to have more than one argument?
Typeof() as currently implemented in *practice* merely acts like
sizeof: it is unary and does not evaluate its argument.
Do you see any reason to make it take more than one argument?
| How else does one create generics of functions with more than one
| arg, like atan2()?
Right now I didn't see anybody talking about "generics of functions."
In this discussion, the thingy that was mentionned is "type-generic
macros".
| Other issues arise when you start looking at standards,
I know.
| depending
| on the variety of existing implementations and applications of a
| language feature.
Do you of know of implementations that implement typeof differently?
If so, how substantial are those differences?
-- Gaby
Jim Balter
> In message <3E069B15...@cW.comdiespammersdie>, Jim Balter
> <Jim.B...@cW.comdiespammersdie> writes
>
>> So enough with the ad hominems and the misrepresentations.
>> My comment is about the *process* and its consequences.
>> I don't know how the problems with the process might be
>> addressed, and I'm not asserting that, if I were on the
>> committee, things would have been better, but the problems
>> do exist and I have every right and reason to point them out,
>> for objective consideration and comment.
>
>
> But your actual experience of the Committee seems to date to an atypical
> couple of meetings of J16.
I was primarily answering the charge that I hadn't "lent a hand"
and therefore had no standing to criticize the work of committee
members. But not only did I lend a hand, but the C Standard is
a public work and is not the property of the committee members,
and the committee is a public body and is not comprised of its members.
Anyone who is affected by them has the right to make critical
comments about the Standard, the committee, the process, whathaveyou.
The atypicality of my experience isn't relevant to the point.
> For a decade the C Standard has been handled
> by WG14. My experience over that decade has been very different (and I
> also, more often than not, fund myself even though I make no money from
> any aspect of C)
>
> The fundamental problem is that the WG14 can only address issues where
> it has one or more available experts. For example you raised the issue
> of 'typeof'. Putting aside the issue of its utility in C (I have no
> doubt that it is useful in C++, and WG21 is addressing that issue for
> the next C++ standard)
As has been pointed out, tgmath.h demonstrates well enough its utility.
> as far as I know there is no one currently active
> on WG14 who felt they understood the implications of typeof sufficiently
> well to propose its adoption. Note that just because an extension works
> well in a specific environment does not mean that it can simply be
> adopted for all.
typeof is provided by gcc, which is implemented across a wide variety
of platforms. I don't know what you mean by "a specific environment",
but that doesn't normally refer to a particular implementation.
typeof has been available in a widely used dialect of C for a long time;
that makes it prior art, and a proper subject for standardization.
As I said, I believe that in this regard the committee loses track
of its purpose, which includes standardizing the C language as used,
rather than exercising personal views as to what is of utility --
I mention this again despite your putting it aside, because Doug
Gwyn talked of utility in his response, and my experience
on the committee, however atypical those meetings might have
been, included people rejecting typeof because they personally
didn't think it was of much use -- and the same claim was made
of offsetof, sigh, but that one made it through.
Not that leaving offsetof out would have been a problem,
since the standard macro implementation is portable,
but there is no way to get the functionality of typeof without
adding it to the language.
--
<J Q B>
Mark McIntyre
<Jim.B...@cW.comdiespammersdie> wrote:
>On 12/23/02 3:21 AM, Francis Glassborow wrote:
>>
>> But your actual experience of the Committee seems to date to an atypical
>> couple of meetings of J16.
>
>I was primarily answering the charge that I hadn't "lent a hand"
>and therefore had no standing to criticize the work of committee
>members.
Perhaps. But this is quite irrelevant in comp.lang.c, so please stop
crossposting it.
>But not only did I lend a hand, but the C Standard is
>a public work and is not the property of the committee members,
>and the committee is a public body and is not comprised of its members.
>Anyone who is affected by them has the right to make critical
>comments about the Standard, the committee, the process, whathaveyou.
>The atypicality of my experience isn't relevant to the point.
You burble elsethread about sophistry, then spout this prime example.
Indeed, the standard is a public work, not owned by the committee
members. Relevance to your argument: nil.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
Jim Balter
> On Fri, 27 Dec 2002 01:39:47 GMT, in comp.lang.c , Jim Balter
> <Jim.B...@cW.comdiespammersdie> wrote:
>
>
>>On 12/23/02 3:21 AM, Francis Glassborow wrote:
>>
>>>But your actual experience of the Committee seems to date to an atypical
>>>couple of meetings of J16.
>>
>>I was primarily answering the charge that I hadn't "lent a hand"
>>and therefore had no standing to criticize the work of committee
>>members.
>
>
> Perhaps. But this is quite irrelevant in comp.lang.c, so please stop
> crossposting it.
>
>
>>But not only did I lend a hand, but the C Standard is
>>a public work and is not the property of the committee members,
>>and the committee is a public body and is not comprised of its members.
>>Anyone who is affected by them has the right to make critical
>>comments about the Standard, the committee, the process, whathaveyou.
>>The atypicality of my experience isn't relevant to the point.
>
>
> You burble elsethread about sophistry, then spout this prime example.
It's not an example, prime or otherwise.
> Indeed, the standard is a public work, not owned by the committee
> members. Relevance to your argument: nil.
The relevance is exactly as I stated it -- even if one "didn't
lend a hand" one can have justification to "criticize others' work";
those are the relevant quotes from this thread. Your apparent personal
hostility is not.
--
<J Q B>
Douglas A. Gwyn
> As I said, I believe that in this regard the committee loses track
> of its purpose, which includes standardizing the C language as used,
> rather than exercising personal views as to what is of utility --
No, it was never the charter of the C standards committee
to bless some particular example of "C as used". There
are many factors that have to be balanced, or if you
prefer, traded off, so it is quite appropriate to leave
out of the standard some particular third-party invention
that has little use but significant cost.
Paul Eggert
> it is quite appropriate to leave out of the standard some particular
> third-party invention that has little use but significant cost.
Of course. But "typeof" costs little to implement, and it has real
use, even in C. Many quite reasonable projects use "typeof" to good
effect. If you want to compile the Linux kernel, for example, your
compiler had better support "typeof".
At some point "typeof" will become the de facto standard. Perhaps it
will even become de jure.
Al Grant
> Of course. But "typeof" costs little to implement, and it has real
> use, even in C. Many quite reasonable projects use "typeof" to good
> effect. If you want to compile the Linux kernel, for example, your
> compiler had better support "typeof".
What are the precise conformance requirements for compiling the
Linux kernel? Are the necessary language extensions specified in
a way that is stable and vendor-neutral enough for other vendors
and the committee to be happy adopting, and that GCC themselves
would defer to? Is there a "Linux Extensions for C" standard?
Features can't be expected to move directly from one vendor's
product documentation into the standard. Of course in this case
some other vendors do support typeof, along with other compiler
compatibility modes (including bug-compatibility), but language
standardization shouldn't work like that.
Paul Eggert
> Are the necessary language extensions specified in a way that is
> stable and vendor-neutral enough for other vendors and the committee
> to be happy adopting, and that GCC themselves would defer to?
Yes. The GNU C extensions (as of GCC 3.2) are specified in
http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/C-Extensions.html
The list of extensions has not changed much recently. Many of the
extensions listed in that page are now part of C99, but since the
manual is also directed at C89 users it still mentions them as
extensions.
Al Grant
> alg...@myrealbox.com (Al Grant) writes:
> > Are the necessary language extensions specified in a way that is
> > stable and vendor-neutral enough for other vendors and the committee
> > to be happy adopting, and that GCC themselves would defer to?
>
> Yes. The GNU C extensions (as of GCC 3.2)
Do you mean the answer to "what does it take to compile the Linux
kernel" is simply "the current GNU C extensions"? If so, it hardly
seems a valid argument to advance for adopting 'typeof' unless there
is a real prospect of C adopting all the others. Which seem to
consist of a mixture, in no particular order, of the cosmetic,
the genuinely useful, attempts to create an entirely different
language, and even several already in the (current) language.
Surely the right way is to work out which of the features have
general usefulness, standardize their spec individually (or in
sensible groups), and consider each one on its merits for adoption.
lawrenc...@eds.com
> alg...@myrealbox.com (Al Grant) writes:
>
>> Are the necessary language extensions specified in a way that is
>> stable and vendor-neutral enough for other vendors and the committee
>> to be happy adopting, and that GCC themselves would defer to?
>
> Yes. The GNU C extensions (as of GCC 3.2) are specified in
>
> http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/C-Extensions.html
No. Those *descriptions* may be stable and to some degree vendor
neutral, but they are not *specifications* that can simply be adopted
into the standard. In most cases, their impact on the syntax and
semantics of the language is not fully addressed, especially in reguards
to obscure "corner" cases. And the GCC developers usually fail to even
consider architectures that they do not consider important when
designing extensions; the committee does not have that liberty.
-Larry Jones
Isn't it sad how some people's grip on their lives is so precarious
that they'll embrace any preposterous delusion rather than face an
occasional bleak truth? -- Calvin
Paul Eggert
> Do you mean the answer to "what does it take to compile the Linux
> kernel" is simply "the current GNU C extensions"?
No. The entire set of extensions obviously suffices, but it is not
all necessary.
> If so, it hardly seems a valid argument to advance for adopting
> 'typeof' unless there is a real prospect of C adopting all the
> others.
One could hardly expect the committee to adopt all the GCC changes
wholesale. Nor do I expect the committee to be swayed by arguments
like "but the Linux kernel uses this feature". So I'm not sure what
your point is.
Historically, the committee has not paid much attention to free
software in general, or to GCC in particular. They have introduced
changes to C seemingly without bothering to check whether GCC had
already done something similar. They have also introduced
incompatible changes to C without seeming to care much how much free
software would broken by the changes. In short, they haven't really
taken free software seriously. This is not too surprising, since the
free software folks were too impoverished or busy (or both) to attend
standardization meetings.
Perhaps this will change in the future, as GCC and other free software
gain importance. Perhaps you can help it to change. Who knows?
> Surely the right way is to work out which of the features have
> general usefulness, standardize their spec individually (or in
> sensible groups), and consider each one on its merits for adoption.
The committee is free to go through the documented GCC extensions.
The documentation is quite clear -- it's just as clear as the
C Standard itself, if not clearer.
But rather than look at all of GCC's extensions, which is a rather
daunting prospect, why not start with 'typeof'? Here's its spec:
http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Typeof.html#Typeof
Is any part of that spec unclear to you?
Paul Eggert
> Those *descriptions* may be stable and to some degree vendor
> neutral, but they are not *specifications* that can simply be
> adopted into the standard.
Undoubtedly they'd have to be translated into standardese, and would
have to use fonts and line-numbering conventions that satisfy ISO, and
so forth. But I don't think that's the issue. The issue is: is the
_feature_ easily standardizable and worth standardizing? If the
answer is "yes" then there should be little issue about dotting the
i's and crossing the t's.
> In most cases, their impact on the syntax and semantics of the
> language is not fully addressed, especially in reguards to obscure
> "corner" cases.
Hmm. Do you have any "corner" cases in mind for the typeof extension
that we were discussing? Here's its spec:
http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Typeof.html#Typeof
Christian Bau
Paul Eggert <egg...@twinsun.com> wrote:
> But rather than look at all of GCC's extensions, which is a rather
> daunting prospect, why not start with 'typeof'? Here's its spec:
>
> http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Typeof.html#Typeof
>
> Is any part of that spec unclear to you?
I wouldn't go so far as calling it a spec. Not that a spec couldn't be
written for typeof, but this is not a spec.
t...@cs.ucr.edu
+ In article <7wof6wx...@sic.twinsun.com>,
+ Paul Eggert <egg...@twinsun.com> wrote:
+
+> But rather than look at all of GCC's extensions, which is a rather
+> daunting prospect, why not start with 'typeof'? Here's its spec:
+>
+> http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Typeof.html#Typeof
+>
+> Is any part of that spec unclear to you?
+
+ I wouldn't go so far as calling it a spec. Not that a spec couldn't be
+ written for typeof, but this is not a spec.
In what sense? The syntax and semantics seem quite clear and
complete. Besides, the authors have provided a reference
implementation.
The challenge is to translate it into the paradigms and style of the
Standard. The GCC folks cleverly side-stepped that problem by
referring to the specs for sizeof and typedef.
Tom Payne
Chris Hills
>alg...@myrealbox.com (Al Grant) writes:
>
>The committee is free to go through the documented GCC extensions.
>The documentation is quite clear -- it's just as clear as the
>C Standard itself, if not clearer.
The committee goes through the standard. The people on the committee
tend to represent commercial vendors. However AFAIK anyone can go to
national panel meetings and put things forwards.
Like any committee based structure, find people on the committee, put
suggestions to them and get them to put the ideas forwards.
Several people on the UK panel are involved with MISRA-C so there is an
input from that. I think the problem with the GNU SW is that AFAIK there
is no central organising group. It's strength is also it's weakness.
There are some people on the UK panel who do use GNU but they don't put
anything forward.... perhaps if the GNU fraternity were to work out what
they want to add to the C standard and then put these things forward via
current panel members or... join the C standards Panels themselves.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Christian Bau
> In comp.std.c Christian Bau <christ...@freeserve.co.uk> wrote:
> + In article <7wof6wx...@sic.twinsun.com>,
> + Paul Eggert <egg...@twinsun.com> wrote:
> +
> +> But rather than look at all of GCC's extensions, which is a rather
> +> daunting prospect, why not start with 'typeof'? Here's its spec:
> +>
> +> http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Typeof.html#Typeof
> +>
> +> Is any part of that spec unclear to you?
> +
> + I wouldn't go so far as calling it a spec. Not that a spec couldn't be
> + written for typeof, but this is not a spec.
>
> In what sense? The syntax and semantics seem quite clear and
> complete. Besides, the authors have provided a reference
> implementation.
You mean "The syntax of using of this keyword looks like sizeof, but the
construct acts semantically like a type name defined with typedef. "?
I would expect a specification of a language feature at least to be
written in proper English. No mention that "typeof" is a reserved word.
Is it one? Does "keyword" mean "reserved word" or does "keyword" mean an
ordinary identifier, that in certain places is interpreted to indicate
some syntax? "looks like sizeof" means to me a superficial resemblance.
An l (lowercase ell) "looks like" a 1 (digit one).
> The challenge is to translate it into the paradigms and style of the
> Standard. The GCC folks cleverly side-stepped that problem by
> referring to the specs for sizeof and typedef.
The challenge is to translate this into a spec. This document was never
intented as a spec, it was intended as documentation and explanation of
this gcc feature.
Francis Glassborow
<ch...@phaedsys.org> writes
>There are some people on the UK panel who do use GNU but they don't put
>anything forward.... perhaps if the GNU fraternity were to work out what
>they want to add to the C standard and then put these things forward via
>current panel members or... join the C standards Panels themselves.
As I understand it key people involved with GCC have repeatedly been
invited to participate at Standards level . However for various reasons
they have not, AFAIK, done so. There were times while we were working
on the C99 release when we very much wanted to hear expert explanations
of some of the extensions in GCC so that we could discuss with their
authors concerns we had with how they might be generalised to apply to
all platforms. Again we did not obtain the input we needed and so had to
work with what we knew and thought we understood.
--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow ACCU
Gabriel Dos Reis
So what would you call it? What technical issues do you think ought to
be addressed?
-- Gaby
t...@cs.ucr.edu
+
+> In comp.std.c Christian Bau <christ...@freeserve.co.uk> wrote:
+> + In article <7wof6wx...@sic.twinsun.com>,
+> + Paul Eggert <egg...@twinsun.com> wrote:
+> +
+> +> But rather than look at all of GCC's extensions, which is a rather
+> +>
+> +> http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Typeof.html#Typeof
+> +>
+> +> Is any part of that spec unclear to you?
+> +
+> + I wouldn't go so far as calling it a spec. Not that a spec couldn't be
+>
+> In what sense? The syntax and semantics seem quite clear and
+> complete. Besides, the authors have provided a reference
+> implementation.
+
+ You mean "The syntax of using of this keyword looks like sizeof, but the
+ construct acts semantically like a type name defined with typedef. "?
Yes -- that's a colloquial way of saying that the syntactic constructs
typeof <unary-expression>
and
typeof ( <type-name> )
are type-specifiers that that specify the type of the corresponding
unary-expression or type-name, respectively.
+ I would expect a specification of a language feature at least to be
+ written in proper English.
Proper specifications should be written in languages with well-defined
syntax and semantics. ;-)
+ No mention that "typeof" is a reserved word.
+ Is it one? Does "keyword" mean "reserved word" or does "keyword" mean an
+ ordinary identifier, that in certain places is interpreted to indicate
+ some syntax?
I presume that "keyword" means here what it means in C89, 6.1.1.
Tom Payne
Christian Bau
Gabriel Dos Reis <g...@integrable-solutions.net> wrote:
Online documentation. That is what it calls itself.
Christian Bau
> In comp.std.c Christian Bau <christ...@freeserve.co.uk> wrote:
> + In article <av90dh$8ar$1...@glue.ucr.edu>, t...@cs.ucr.edu wrote:
> +
> +> In comp.std.c Christian Bau <christ...@freeserve.co.uk> wrote:
> + You mean "The syntax of using of this keyword looks like sizeof, but the
> + construct acts semantically like a type name defined with typedef. "?
>
> Yes -- that's a colloquial way of saying that the syntactic constructs
>
> typeof <unary-expression>
>
> and
>
> typeof ( <type-name> )
>
> are type-specifiers that that specify the type of the corresponding
> unary-expression or type-name, respectively.
That is not how I understood it (A looks like B is to me a colloquial
way of saying that there are certain similarities; nothing more). If you
need to post an explanation what it means then it is not a spec. Which
that web page itself never claimed to be, so this is nothing the author
should be blamed for.
If someone writes a spec everyone has to be able to understand it and
interpret it correctly _without knowing the subject beforehand_. This is
not a spec.
t...@cs.ucr.edu
+ In article <ava15p$c4k$1...@glue.ucr.edu>, t...@cs.ucr.edu wrote:
+
+> In comp.std.c Christian Bau <christ...@freeserve.co.uk> wrote:
+> +
+> +> In comp.std.c Christian Bau <christ...@freeserve.co.uk> wrote:
+
+> + construct acts semantically like a type name defined with typedef. "?
+>
+> Yes -- that's a colloquial way of saying that the syntactic constructs
+>
+> typeof <unary-expression>
+>
+> and
+>
+> typeof ( <type-name> )
+>
+> are type-specifiers that that specify the type of the corresponding
+> unary-expression or type-name, respectively.
+
+ That is not how I understood it (A looks like B is to me a colloquial
+ way of saying that there are certain similarities; nothing more).
The looks of a language feature would obviously refer to its syntax,
but if that isn't clear, then perhaps better wording should have been
chosen.
+ If you need to post an explanation what it means then it is not a spec.
[...]
+ If someone writes a spec everyone has to be able to understand it and
+ interpret it correctly _without knowing the subject beforehand_.
One of the main functions of this very newsgroup is the posting of
explanations of a standard for the benefit of folks who are not able
to interpret it correctly.
FWIW, I've never used typeof and had no idea that GCC had such a
feature until yesterday. I have, however, often wished for such
a feature, especially when using the STL.
Tom Payne
Douglas A. Gwyn
> Historically, the committee has not paid much attention to free
> software in general, or to GCC in particular. They have introduced
> changes to C seemingly without bothering to check whether GCC had
> already done something similar. They have also introduced
> incompatible changes to C without seeming to care much how much free
> software would broken by the changes. In short, they haven't really
> taken free software seriously. This is not too surprising, since the
> free software folks were too impoverished or busy (or both) to attend
> standardization meetings.
That is not accurate. On several occasions when new functionality
was being considered, GCC's implementation was examined. For
reasons that vary with the specific case, often a somewhat
different specification was adopted after discussion of the
pros and cons. That's no different than <varargs.h> versus
<stdarg.h>. It has nothing to do with "free software" but
rather with the trade-offs negotiated among those who bothered
to participate rather than merely carp after the fact. Indeed
there have been GCC users active on the C standards committee
for several years, some of them paying their own way and taking
time out from busy schedules.
Douglas A. Gwyn
> Undoubtedly they'd have to be translated into standardese, and would
> have to use fonts and line-numbering conventions that satisfy ISO, and
> so forth. But I don't think that's the issue. The issue is: is the
> _feature_ easily standardizable and worth standardizing? If the
> answer is "yes" then there should be little issue about dotting the
> i's and crossing the t's.
I agree with that, in principle. In fact "typeof" has on
occasion been considered for standardization, and the answer
so far has been "no", or at least lack of a consensus that
the answer is "yes".
t...@cs.ucr.edu
+ Paul Eggert wrote:
+> Undoubtedly they'd have to be translated into standardese, and would
+> have to use fonts and line-numbering conventions that satisfy ISO, and
+> so forth. But I don't think that's the issue. The issue is: is the
+> _feature_ easily standardizable and worth standardizing? If the
+> answer is "yes" then there should be little issue about dotting the
+> i's and crossing the t's.
+
+ I agree with that, in principle. In fact "typeof" has on
+ occasion been considered for standardization, and the answer
+ so far has been "no", or at least lack of a consensus that
+ the answer is "yes".
I'd be interested in the objections to such a feature, since its
specification and implementation seem extremely straightforward.
Tom Payne
Douglas A. Gwyn
> FWIW, I've never used typeof and had no idea that GCC had such a
> feature until yesterday. I have, however, often wished for such
> a feature, especially when using the STL.
Yes, typeof could be extremely handy in conjunction with
templates. Its utility in C, however, seems quite limited.
I've encounted a few situations in C programming where I
could have used typeof, but managed to do okay without it.
Douglas A. Gwyn
> I'd be interested in the objections to such a feature, since its
> specification and implementation seem extremely straightforward.
Without agreeing with that characterization, assuming for
the sake of discussion that it were true, that would still
not justify addition of the feature to Standard C. There
are many, many possible new features for which a similar
claim could be made, and in order to maintain some control
over the size of the language (and thus its practicality)
we also require that a strong case be made that the feature
is needed. The committee hasn't yet heard a sufficiently
convincing case for sizeof, despite some individual
sentiment that it would sometimes be nice to have. We
understand that there are a *lot* of things that, considered
individually, would be nice to have, but that allowing them
all into the language would produce a result that would
*not* be nice to have. So we defer to the general principle.
t...@cs.ucr.edu
+> I'd be interested in the objections to such a feature, since its
+> specification and implementation seem extremely straightforward.
+
+ Without agreeing with that characterization, assuming for
+ the sake of discussion that it were true, that would still
+ not justify addition of the feature to Standard C. There
+ are many, many possible new features for which a similar
+ claim could be made, and in order to maintain some control
+ over the size of the language (and thus its practicality)
+ we also require that a strong case be made that the feature
+ is needed. The committee hasn't yet heard a sufficiently
+ convincing case for sizeof, despite some individual
^^^^^^
;-)
+ sentiment that it would sometimes be nice to have. We
+ understand that there are a *lot* of things that, considered
+ individually, would be nice to have, but that allowing them
+ all into the language would produce a result that would
+ *not* be nice to have. So we defer to the general principle.
So there are any significant arguments against it beyond simple
inertia.
Tom Payne
Douglas A. Gwyn
Yes, I already explained that not exercising restraint
would lead to a much more bloated language, which has
several bad consequences that you ought to be able to
figure out..
Ross Ridge
> If so, it hardly seems a valid argument to advance for adopting
> 'typeof' unless there is a real prospect of C adopting all the
> others.
Paul Eggert <egg...@twinsun.com> wrote:
>One could hardly expect the committee to adopt all the GCC changes
>wholesale.
In particular it's unlikely that they'd adopt GCC's peculiar inline
assembly syntax, and the Linux kernel is highly dependent on that.
>Nor do I expect the committee to be swayed by arguments
>like "but the Linux kernel uses this feature".
Apparently you thought someone might be swayed by it, or you wouldn't've
mentioned it.
>So I'm not sure what your point is.
I beleive his point is that the Linux kernel isn't a good example of of
how "typeof" is used in actual code because the kernel is dependent on
a large number of GCC'isms that have no chance being incorporated into
Standard C.
>Historically, the committee has not paid much attention to free
>software in general, or to GCC in particular. They have introduced
>changes to C seemingly without bothering to check whether GCC had
>already done something similar.
I dunno, it seems like to me that they did. C99 has a fair number of
things seen first in GCC.
> They have also introduced incompatible changes to C without seeming
>to care much how much free software would broken by the changes.
True. But I don't think they really looked too hard to see how much of
any kind of software would break.
> In short, they haven't really taken free software seriously. This is
>not too surprising, since the free software folks were too impoverished
>or busy (or both) to attend standardization meetings.
Except that being free and widely available, GCC is probably the only
compiler that a majority of committee have all used.
>The committee is free to go through the documented GCC extensions.
>The documentation is quite clear -- it's just as clear as the
>C Standard itself, if not clearer.
>
>But rather than look at all of GCC's extensions, which is a rather
>daunting prospect, why not start with 'typeof'? Here's its spec:
That "spec" isn't very convincing that typeof is at all useful.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/u/rridge/
db //
t...@cs.ucr.edu
+ > beyond simple inertia.
+
+ Yes, I already explained that not exercising restraint
+ would lead to a much more bloated language, which has
+ several bad consequences that you ought to be able to
+ figure out..
I fully support a bit of conservatism wrt to language extensions and
agree that the onus should be on proposers to show that benefits
outweigh the clutter cost.
Tom Payne
Gabriel Dos Reis
| > | I wouldn't go so far as calling it a spec. Not that a spec couldn't be
| > | written for typeof, but this is not a spec.
| >
| > So what would you call it? What technical issues do you think ought to
| > be addressed?
|
| Online documentation. That is what it calls itself.
Thanks. However, that answers only one part of my post.
-- Gaby
Gabriel Dos Reis
Yeah, one could manage to do without any single feature in C. So the
argument against "typeof" in C can't that.
-- Gaby
Jim Balter
> Jim Balter wrote:
>
>> As I said, I believe that in this regard the committee loses track
>> of its purpose, which includes standardizing the C language as used,
>> rather than exercising personal views as to what is of utility --
>
>
> No, it was never the charter of the C standards committee
> to bless some particular example of "C as used".
So that charter of the committee is to guarantee that people aren't
able to make their code portable, the way they did with
variadic macros (where many common cases that are coded
with gcc's version *cannot* be coded in C99)?
> There
> are many factors that have to be balanced, or if you
> prefer, traded off, so it is quite appropriate to leave
> out of the standard some particular third-party invention
> that has little use but significant cost.
And again, it is your *personal* view that typeof has little use;
you obviously are not familiar with the uses. And as for cost --
cost to whom? Cost/benefit analyses are only valid when the same
parties pay the costs and reap the benfits. This goes back to
my original comment about where the committee's commitments lie.
What's the cost of converting
a += (typeof(a))b * c;
to Standard C?
--
<J Q B>
Jim Balter
I too have managed to write fragile, error prone code like
a += (type_of_a_the_last_time_I_looked)b * c;
instead of
a += (typeof(a))b * c;
There are a lot of things that people "manage" to do in C.
That was my original point, when I wrote "resulted in large but
unnecessary (other than job security) efforts to achieve portability"
and "people find ways to deal with failures of the language to provide
necessary support, by creating header files filled with all sorts of
gross stuff", comments that you brushed aside by claiming that I don't
know what I'm talking about (of course I am not perfectly informed,
and neither are you; that's why people have exchanges in newsgroups,
unless they are so arrogant as to be present merely to dispense
their wisdom to the receiving masses) and that I didn't "lend a hand"
(which was neither relevant nor true).
--
<J Q B>
P.J. Plauger
news:3E19DA...@cW.comdiespammersdie...
> On 12/29/02 12:56 AM, Douglas A. Gwyn wrote:
> > Jim Balter wrote:
> >
> >> As I said, I believe that in this regard the committee loses track
> >> of its purpose, which includes standardizing the C language as used,
> >> rather than exercising personal views as to what is of utility --
> >
> >
> > No, it was never the charter of the C standards committee
> > to bless some particular example of "C as used".
>
> So that charter of the committee is to guarantee that people aren't
> able to make their code portable, the way they did with
> variadic macros (where many common cases that are coded
> with gcc's version *cannot* be coded in C99)?
Uh, the logic is a little sloppy here. There's a world of difference
between not blessing some particular usage and guaranteeing that
people can't write portable code.
> > There
> > are many factors that have to be balanced, or if you
> > prefer, traded off, so it is quite appropriate to leave
> > out of the standard some particular third-party invention
> > that has little use but significant cost.
>
> And again, it is your *personal* view that typeof has little use;
I believe that Doug reported accurately the several occasions when
the *entire* C committee considered typeof and rejected it.
> you obviously are not familiar with the uses.
I obviously am, having used it to advantage in commercial software.
And I'd have to vote against adding typeof alone, since IME it's
of little use in C without one or two other features that are of
less dubious merit, taken alone. (It's rather more useful in C++,
thanks mostly to templates.)
> And as for cost --
> cost to whom? Cost/benefit analyses are only valid when the same
> parties pay the costs and reap the benfits.
Really? Many's the time when the C committee has chosen to do
something that's expensive for implementors simply because it's
beneficial to users. (In C++, this happens even more.) And
implementors have always been well represented on the C committee
(if not on the C++ committee).
> This goes back to
> my original comment about where the committee's commitments lie.
Speculate away.
> What's the cost of converting
>
> a += (typeof(a))b * c;
>
> to Standard C?
Beats me. It wasn't in K&R C and has never been in any draft of the
C Standard. So I guess you're running a risk in writing it in any
program you hope to make portable, neh? Of course, if you're content
to stay in the GCC ghetto, you have no problem.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jim Balter
> In message <+Ez9CqAV...@phaedsys.demon.co.uk>, Chris Hills
> <ch...@phaedsys.org> writes
>
>> There are some people on the UK panel who do use GNU but they don't put
>> anything forward.... perhaps if the GNU fraternity were to work out what
>> they want to add to the C standard and then put these things forward via
>> current panel members or... join the C standards Panels themselves.
>
>
> As I understand it key people involved with GCC have repeatedly been
> invited to participate at Standards level . However for various reasons
> they have not, AFAIK, done so. There were times while we were working
> on the C99 release when we very much wanted to hear expert explanations
> of some of the extensions in GCC so that we could discuss with their
> authors concerns we had with how they might be generalised to apply to
> all platforms. Again we did not obtain the input we needed and so had to
> work with what we knew and thought we understood.
It might be worthwhile for the committee to create a gcc liason subcommittee,
responsible for learning about gcc and representing it before the committee.
This would go beyond trying to get some notoriously eccentric personality
like Richard Stallman to show up at meetings. This is, I believe, what a
commitment to the user community would entail, a community that goes way
beyond Stallman or the maintainers of gcc, to the *users* of gcc.
It isn't adequate to say, e.g., as I seen it said by Peter Seebach, that
variadic macros are broken in C99 because communications broke down between
the committee and the gcc folks (http://groups.google.com/groups?hl=en&lr=lang_en&ie=UTF-8&safe=off&frame=right&th=8071d8e267a54adf&seekm=7wk7wx3jxm.fsf%40sic.twinsun.com#link3).
The committee is a public organization with responsibility toward the C community;
much as people might wish it, the same does not apply to Stallman et. al.
--
<J Q B>
Gabriel Dos Reis
| > you obviously are not familiar with the uses.
|
| I obviously am, having used it to advantage in commercial software.
| And I'd have to vote against adding typeof alone, since IME it's
| of little use in C without one or two other features that are of
| less dubious merit, taken alone. (It's rather more useful in C++,
| thanks mostly to templates.)
What are those "one or two other features that are of less dubious
merit, taken alone" you're thinking about?
(I guess you're not thinking of templates ;-)
-- Gaby
Jim Balter
> Paul Eggert wrote:
>
>> Historically, the committee has not paid much attention to free
>> software in general, or to GCC in particular. They have introduced
>> changes to C seemingly without bothering to check whether GCC had
>> already done something similar. They have also introduced
>> incompatible changes to C without seeming to care much how much free
>> software would broken by the changes. In short, they haven't really
>> taken free software seriously. This is not too surprising, since the
>> free software folks were too impoverished or busy (or both) to attend
>> standardization meetings.
>
>
> That is not accurate. On several occasions when new functionality
> was being considered, GCC's implementation was examined. For
> reasons that vary with the specific case, often a somewhat
> different specification was adopted after discussion of the
> pros and cons. That's no different than <varargs.h> versus
> <stdarg.h>. It has nothing to do with "free software" but
> rather with the trade-offs negotiated among those who bothered
> to participate rather than merely carp after the fact.
This ad hominem whining is tiresome -- you brandish your having participated
as a club to bash those who disagree or have criticisms; it's a distinctly
anti-intellectual mode. And some who participated have a different view
than your convenient generalities; e.g.,
http://groups.google.com/groups?q=seebach+variadic+gcc&hl=en&lr=lang_en&ie=UTF-8&safe=off&selm=TTmT3.953%24rK2.56975%40ptah.visi.com&rnum=2
--
<J Q B>
Jim Balter
> In comp.std.c Paul Eggert <egg...@twinsun.com> wrote:
>
>>alg...@myrealbox.com (Al Grant) writes:
>>
>>
>>>Are the necessary language extensions specified in a way that is
>>>stable and vendor-neutral enough for other vendors and the committee
>>>to be happy adopting, and that GCC themselves would defer to?
>>
>>Yes. The GNU C extensions (as of GCC 3.2) are specified in
>>
>>http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/C-Extensions.html
>
>
> No. Those *descriptions* may be stable and to some degree vendor
> neutral, but they are not *specifications* that can simply be adopted
> into the standard. In most cases, their impact on the syntax and
> semantics of the language is not fully addressed, especially in reguards
> to obscure "corner" cases. And the GCC developers usually fail to even
> consider architectures that they do not consider important when
> designing extensions; the committee does not have that liberty.
>
> -Larry Jones
>
> Isn't it sad how some people's grip on their lives is so precarious
> that they'll embrace any preposterous delusion rather than face an
> occasional bleak truth? -- Calvin
Like the delusion that typeof is architecture-specific, or that such
an irrelevant observation somehow justifies its omission from the standard?
--
<J Q B>
Witless
> On 1/5/03 4:25 PM, Douglas A. Gwyn wrote:
> > t...@cs.ucr.edu wrote:
> >
> >> FWIW, I've never used typeof and had no idea that GCC had such a
> >> feature until yesterday. I have, however, often wished for such
> >> a feature, especially when using the STL.
> >
> >
> > Yes, typeof could be extremely handy in conjunction with
> > templates. Its utility in C, however, seems quite limited.
> > I've encounted a few situations in C programming where I
> > could have used typeof, but managed to do okay without it.
>
> I too have managed to write fragile, error prone code like
>
> a += (type_of_a_the_last_time_I_looked)b * c;
>
> instead of
>
> a += (typeof(a))b * c;
This is an extension of the One Definition Rule applied to variables. It
tends to limit type skews during maintenance, which is a prevalent form of
_silent_ error, and one with a trivial fix: typeof.
The alternative is fairly ugly:
typedef int type_of_a;
type_of_a a;
a += (type_of_a) b + c;
Why pollute the code with an extraneous symbol, type_of_a, when the
equivalent expression, typeof(a), has no linguistic downside? This is not
language bloat, this is language elegance.
Jim Balter
> "Jim Balter" <Jim.B...@cW.comdiespammersdie> wrote in message
>>you obviously are not familiar with the uses.
>
>
> I obviously am
I wasn't addressing you.
> if you're content
> to stay in the GCC ghetto, you have no problem.
Some people think of China as a ghetto.
--
<J Q B>
Jim Balter
Not considered a valid argument, apparently.
--
<J Q B>
Gabriel Dos Reis
| And the GCC developers usually fail to even
| consider architectures that they do not consider important when
| designing extensions; the committee does not have that liberty.
What is so architecture specific about typeof?
-- Gaby
Tony Finch
>
>Historically, the committee has not paid much attention to free
>software in general, or to GCC in particular. They have introduced
>changes to C seemingly without bothering to check whether GCC had
>already done something similar.
There are usually good reasons that the GCC extension was not blessed.
E.g. in the case of the struct hack, ANSI C doesn't have zero-sized
objects so the array[0] syntax couldn't be used.
Tony.
--
f.a.n.finch <d...@dotat.at> http://dotat.at/
FISHER GERMAN BIGHT HUMBER: NORTH OR NORTHEAST 4 OR 5, OCCASIONALLY 6. WINTRY
SHOWERS. MODERATE OR GOOD.
Jim Balter
> In article <av90dh$8ar$1...@glue.ucr.edu>, t...@cs.ucr.edu wrote:
>
>
>>In comp.std.c Christian Bau <christ...@freeserve.co.uk> wrote:
>>+ Paul Eggert <egg...@twinsun.com> wrote:
>>+
>>+> But rather than look at all of GCC's extensions, which is a rather
>>+> daunting prospect, why not start with 'typeof'? Here's its spec:
>>+>
>>+> http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Typeof.html#Typeof
>>+>
>>+> Is any part of that spec unclear to you?
>>+
>>+ I wouldn't go so far as calling it a spec. Not that a spec couldn't be
>>+ written for typeof, but this is not a spec.
>>
>>In what sense? The syntax and semantics seem quite clear and
>>complete. Besides, the authors have provided a reference
>>implementation.
>
> You mean "The syntax of using of this keyword looks like sizeof, but the
>
> written in proper English. No mention that "typeof" is a reserved word.
> Is it one? Does "keyword" mean "reserved word" or does "keyword" mean an
> ordinary identifier, that in certain places is interpreted to indicate
> some syntax? "looks like sizeof" means to me a superficial resemblance.
> An l (lowercase ell) "looks like" a 1 (digit one).
>
>
>>The challenge is to translate it into the paradigms and style of the
>>Standard. The GCC folks cleverly side-stepped that problem by
>>referring to the specs for sizeof and typedef.
>
>
> The challenge is to translate this into a spec. This document was never
> intented as a spec, it was intended as documentation and explanation of
> this gcc feature.
The challenge has been met:
Clive writes later in the thread that it took him 20 minutes.
Hopefully this will address your, um, petite points.
--
<J Q B>
Jim Balter
> Paul Eggert <egg...@twinsun.com> wrote:
>
>>Historically, the committee has not paid much attention to free
>>software in general, or to GCC in particular. They have introduced
>>changes to C seemingly without bothering to check whether GCC had
>>already done something similar.
>
>
> There are usually good reasons that the GCC extension was not blessed.
> E.g. in the case of the struct hack, ANSI C doesn't have zero-sized
> objects so the array[0] syntax couldn't be used.
So it's physically or logically impossible to modify the standard
so that array[0] has a clear and consistent semantics?
But really, I've never understood the problem, since
struct foo
{
...
sometype bar[1];
};
...
struct foo *p = malloc(offsetof(struct foo, bar) + (sizeof(*p->bar) * nbars));
works just fine.
--
<J Q B>
P.J. Plauger
> It might be worthwhile for the committee to create a gcc liason subcommittee,
> responsible for learning about gcc and representing it before the committee.
> This would go beyond trying to get some notoriously eccentric personality
> like Richard Stallman to show up at meetings. This is, I believe, what a
> commitment to the user community would entail, a community that goes way
> beyond Stallman or the maintainers of gcc, to the *users* of gcc.
If you believe that strongly enough, you'll become active in J16 and head
up that committee.
> It isn't adequate to say, e.g., as I seen it said by Peter Seebach, that
> variadic macros are broken in C99 because communications broke down between
> the committee and the gcc folks
(http://groups.google.com/groups?hl=en&lr=lang_en&ie=UTF-8&safe=off&frame=right&th=8071d8e267a54adf&
seekm=7wk7wx3jxm.fsf%40sic.twinsun.com#link3).
It's adequate enough for me.
> The committee is a public organization with responsibility toward the C community;
> much as people might wish it, the same does not apply to Stallman et. al.
The committee has an obligation to the National Bodies who participate at
the ISO level. Each NB has whatever obligation it determines toward its
internal constituencies. You *could* suggest to ISO that it amend the
UN treaty under which it operates...
P.J. Plauger
news:m3r8bqj...@uniton.integrable-solutions.net...
The one compelling use for typeof I find in C is for building macros
that expand to brace-enclosed expressions. So we'd need to add those,
in some form (and define all the corner cases left floating in GCC).
But to get user specifiable generics, we also need some way to get
type promotion and type balancing akin to what the compiler does with
expression. Yes, you can do much of this with typeof and clever
expressions, but they have to be *very* clever (read: incomprehensible)
to get all the tgmath.h cases right.
HTH,
Jim Balter
> "Jim Balter" <Jim.B...@cW.comdiespammersdie> wrote in message
> news:3E19E52C...@cW.comdiespammersdie...
>
>
>>It might be worthwhile for the committee to create a gcc liason subcommittee,
>>responsible for learning about gcc and representing it before the committee.
>>This would go beyond trying to get some notoriously eccentric personality
>>like Richard Stallman to show up at meetings. This is, I believe, what a
>>commitment to the user community would entail, a community that goes way
>>beyond Stallman or the maintainers of gcc, to the *users* of gcc.
>
>
> If you believe that strongly enough, you'll become active in J16 and head
> up that committee.
The gcc user community shouldn't be held hostage to *my* time commitments
or eccentricities, either. That's implicit in what I wrote, but I already
know what to expect from you on the score of reading comprehension.
--
<J Q B>
P.J. Plauger
> On 1/5/03 3:26 PM, Douglas A. Gwyn wrote:
> > Paul Eggert wrote:
> >
> >> Historically, the committee has not paid much attention to free
> >> software in general, or to GCC in particular. They have introduced
> >> changes to C seemingly without bothering to check whether GCC had
> >> already done something similar. They have also introduced
> >> incompatible changes to C without seeming to care much how much free
> >> software would broken by the changes. In short, they haven't really
> >> taken free software seriously. This is not too surprising, since the
> >> free software folks were too impoverished or busy (or both) to attend
> >> standardization meetings.
> >
> > That is not accurate. On several occasions when new functionality
> > was being considered, GCC's implementation was examined. For
> > reasons that vary with the specific case, often a somewhat
> > different specification was adopted after discussion of the
> > pros and cons. That's no different than <varargs.h> versus
> > <stdarg.h>. It has nothing to do with "free software" but
> > rather with the trade-offs negotiated among those who bothered
> > to participate rather than merely carp after the fact.
>
> This ad hominem whining is tiresome
You need to brush up on the meaning of ad hominem. Seems to me he
addressed the accuracy of the statement with facts that can be
independently verified. An ad hominem attack would go after the
person instead of the position. Even the disparaging remark about
those who carp happens to be true, however uncomfortable to the
carpers.
> -- you brandish your having participated
> as a club to bash those who disagree or have criticisms;
Actually, he's correcting misstatements of fact based on his superior
knowledge of the situation, having devoted nearly 20 frigging years
of his life to standardizing C. I don't see any bashing here, just
correcting the record.
> it's a distinctly
> anti-intellectual mode.
Why do I feel an overwhelming urge to say, ``Nyah. Takes one to know one''?
But I won't.
> And some who participated have a different view
> than your convenient generalities; e.g.,
>
http://groups.google.com/groups?q=seebach+variadic+gcc&hl=en&lr=lang_en&ie=UTF-8&safe=off&selm=TTmT3
.953%24rK2.56975%40ptah.visi.com&rnum=2
Why yes. The C committee consists of many people with different viewpoints.
That they differ in some respects doesn't necessarily make any one of them
wrong. Get used to it.
P.J. Plauger
> >>Yes. The GNU C extensions (as of GCC 3.2) are specified in
> >>
> >>http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/C-Extensions.html
> >
> >
> > No. Those *descriptions* may be stable and to some degree vendor
> > neutral, but they are not *specifications* that can simply be adopted
> > into the standard. In most cases, their impact on the syntax and
> > semantics of the language is not fully addressed, especially in reguards
> > to obscure "corner" cases. And the GCC developers usually fail to even
> > consider architectures that they do not consider important when
> > designing extensions; the committee does not have that liberty.
> >
> > -Larry Jones
> >
> > Isn't it sad how some people's grip on their lives is so precarious
> > that they'll embrace any preposterous delusion rather than face an
> > occasional bleak truth? -- Calvin
>
> Like the delusion that typeof is architecture-specific, or that such
> an irrelevant observation somehow justifies its omission from the standard?
You have an incredible capacity to read what you want to in other people's
words. For a person who celebrates logic, you have a weak grasp of the
deductive process.
P.J. Plauger
> On 1/6/03 12:03 PM, P.J. Plauger wrote:
> > "Jim Balter" <Jim.B...@cW.comdiespammersdie> wrote in message
>
> >>you obviously are not familiar with the uses.
> >
> >
> > I obviously am
>
> I wasn't addressing you.
Oh, sorry. I thought this was a public forum. Didn't mean to
eavesdrop.
> > if you're content
> > to stay in the GCC ghetto, you have no problem.
>
> Some people think of China as a ghetto.
And in some dimensions it is.
P.J. Plauger
Nothing, necessarily, that I know of. Did he say it was? Seems to me
his subject was rather broader than typeof.
Gabriel Dos Reis
| "Gabriel Dos Reis" <g...@integrable-solutions.net> wrote in message
| news:m3r8bqj...@uniton.integrable-solutions.net...
|
| > "P.J. Plauger" <p...@dinkumware.com> writes:
| >
| > | > you obviously are not familiar with the uses.
| > |
| > | I obviously am, having used it to advantage in commercial software.
| > | And I'd have to vote against adding typeof alone, since IME it's
| > | of little use in C without one or two other features that are of
| > | less dubious merit, taken alone. (It's rather more useful in C++,
| > | thanks mostly to templates.)
| >
| > What are those "one or two other features that are of less dubious
| > merit, taken alone" you're thinking about?
| >
| > (I guess you're not thinking of templates ;-)
|
| The one compelling use for typeof I find in C is for building macros
| that expand to brace-enclosed expressions.
Aha, the famous GNU C's "statement expression"...
| So we'd need to add those,
| in some form (and define all the corner cases left floating in GCC).
I understand. I believe that that sub-specification is one the
irritating things we've found in the GNU C++ front (some are even
dreaming of removing it from g++ ;-). I think I get your point.
| But to get user specifiable generics, we also need some way to get
| type promotion and type balancing akin to what the compiler does with
| expression.
Hmm, this part I don't understand. What are the issues here?
statement-expressions are primary-expressions, as such the usual
type promotion rules apply, no? (I suspect I'm missing something).
| Yes, you can do much of this with typeof and clever
| expressions, but they have to be *very* clever (read: incomprehensible)
| to get all the tgmath.h cases right.
I completely agree.
-- Gaby
P.J. Plauger
> > There are usually good reasons that the GCC extension was not blessed.
> > E.g. in the case of the struct hack, ANSI C doesn't have zero-sized
> > objects so the array[0] syntax couldn't be used.
>
> So it's physically or logically impossible to modify the standard
> so that array[0] has a clear and consistent semantics?
No, and he didn't say that. (Your creative reading again, I assume.)
The impact of zero-sized objects is pervasive. It's not impossible
to change C to tolerate them (particularly given the success of C++
in incorporating them), but that doesn't make it easy.
> But really, I've never understood the problem, since
Uh, huh.
> struct foo
> {
> ...
> sometype bar[1];
> };
>
> ...
> struct foo *p = malloc(offsetof(struct foo, bar) + (sizeof(*p->bar) * nbars));
>
> works just fine.
And for slightly different reasons, that were easy to think through
and keep localized.
P.J. Plauger
> >>It might be worthwhile for the committee to create a gcc liason subcommittee,
> >>responsible for learning about gcc and representing it before the committee.
> >>This would go beyond trying to get some notoriously eccentric personality
> >>like Richard Stallman to show up at meetings. This is, I believe, what a
> >>commitment to the user community would entail, a community that goes way
> >>beyond Stallman or the maintainers of gcc, to the *users* of gcc.
> >
> >
> > If you believe that strongly enough, you'll become active in J16 and head
> > up that committee.
>
> The gcc user community shouldn't be held hostage to *my* time commitments
> or eccentricities, either. That's implicit in what I wrote, but I already
> know what to expect from you on the score of reading comprehension.
Oh, I understood you well enough. I was merely offering a creative solution,
the one that usually works when people want a standards committee to do
something for them. The C committee shouldn't be held hostage to *your*
eccentricities.
P.J. Plauger
> | > What are those "one or two other features that are of less dubious
> | > merit, taken alone" you're thinking about?
> | >
> | > (I guess you're not thinking of templates ;-)
> |
> | The one compelling use for typeof I find in C is for building macros
> | that expand to brace-enclosed expressions.
>
> Aha, the famous GNU C's "statement expression"...
>
> | So we'd need to add those,
> | in some form (and define all the corner cases left floating in GCC).
>
> I understand. I believe that that sub-specification is one the
> irritating things we've found in the GNU C++ front (some are even
> dreaming of removing it from g++ ;-). I think I get your point.
>
> | But to get user specifiable generics, we also need some way to get
> | type promotion and type balancing akin to what the compiler does with
> | expression.
>
> Hmm, this part I don't understand. What are the issues here?
> statement-expressions are primary-expressions, as such the usual
> type promotion rules apply, no? (I suspect I'm missing something).
Try writing one or two type-generic functions, using typeof and
statement expressions, and you should see what I mean.
> | Yes, you can do much of this with typeof and clever
> | expressions, but they have to be *very* clever (read: incomprehensible)
> | to get all the tgmath.h cases right.
>
> I completely agree.
Thanks.
Gabriel Dos Reis
| > | But to get user specifiable generics, we also need some way to get
| > | type promotion and type balancing akin to what the compiler does with
| > | expression.
| >
| > Hmm, this part I don't understand. What are the issues here?
| > statement-expressions are primary-expressions, as such the usual
| > type promotion rules apply, no? (I suspect I'm missing something).
|
| Try writing one or two type-generic functions, using typeof and
| statement expressions, and you should see what I mean.
Let me see: Are you talking of, say, pow(x, n) which -- if it were to
be written at user-level -- would require means to determine the type
resulting from the usual conversions applied to "x" and "n"?
-- Gaby
Chris Hills
<Jim.B...@cW.comdiespammersdie> writes
>On 1/5/03 4:24 AM, Francis Glassborow wrote:
>> In message <+Ez9CqAV...@phaedsys.demon.co.uk>, Chris Hills
>> <ch...@phaedsys.org> writes
>>
>>> There are some people on the UK panel who do use GNU but they don't put
>>> anything forward.... perhaps if the GNU fraternity were to work out what
>>> they want to add to the C standard and then put these things forward via
>>> current panel members or... join the C standards Panels themselves.
>>
>>
>> As I understand it key people involved with GCC have repeatedly been
>> invited to participate at Standards level . However for various reasons
>> they have not, AFAIK, done so. There were times while we were working
>> on the C99 release when we very much wanted to hear expert explanations
>> of some of the extensions in GCC so that we could discuss with their
>> authors concerns we had with how they might be generalised to apply to
>> all platforms. Again we did not obtain the input we needed and so had to
>> work with what we knew and thought we understood.
>
>It might be worthwhile for the committee to create a gcc liason subcommittee,
>responsible for learning about gcc and representing it before the committee.
Who? Not the C committee? I assume you mean a GCC committee to present
things to the C Panel?
If you wan things included in the standard it is up to you to do the
work to get them in. Not the C committee to find them. In the UK the
panel is made up of people giving their own time and effort. I would
expect no less from the Gcc supporters.
>The committee is a public organization with responsibility toward the C
>community;
Yes.... it is made up of the C community. If there is a part of the C
community it does not represent it is up to that part of the community
to make it self heard.
Regards
Chris
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Douglas A. Gwyn
> But really, I've never understood the problem, since
> struct foo
> {
> ...
> sometype bar[1];
> };
> ...
> struct foo *p = malloc(offsetof(struct foo, bar) + (sizeof(*p->bar) *
> nbars));
> works just fine.
No, it doesn't. As you say, you've never understood the
problem. Perhaps doing so should precede criticism.
Douglas A. Gwyn
> The impact of zero-sized objects is pervasive. It's not impossible
> to change C to tolerate them (particularly given the success of C++
> in incorporating them), but that doesn't make it easy.
If somebody wants to reopen this issue for the next major
revision of the C standard, I guess I'm still the official
point of contact for zero-sized objects in C. Unfortunately
in this capacity I've received only a handful of comments
over the years, which perhaps indicates the level of
interest in having such support.
I think it isn't too hard to allow zero-sized objects;
the usual concern is that members of an array of such
objects would have addresses that compare equal, but I
don't see why that bothers anybody. I *think* they may
be worried that some existing code could malfunction,
but it's pretty obvious that there would be no change
in the behavior of existing code as the result of
allowing a pure extension to the language.
Douglas A. Gwyn
> The alternative is fairly ugly:
Also wrong. Look more closely at the original.
I don't understand why the example is important.
I don't find your alternative (suitably corrected)
in any of my code. There might be an occasional
cast of an operand to uintmax_t, relying on the
compiler to use an equivalent narrower width when
feasible in the generated code.
Peter L. Montgomery
I favor zero-length arrays (and other zero-length entities
such as empty structs). What I see breaking is the paradigm
for the dimensions of a multi-dimensional array.
If one declares
double array[N1][N2];
where N1 and N2 are compile-time constants, then
sizeof(array) / sizeof(array[0])
evaluates as (N1*N2*sizeof(double)) / (N1*sizeof(double)) = N2.
This formula won't work if N1 might be zero.
--
A local drug store selling wine boasts a drug and alcohol free workplace.
A local grocery store advertises Hot Buys even on frozen foods.
Peter-Lawren...@cwi.nl Home: San Rafael, California
Microsoft Research and CWI