Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #1796 > unrolled thread

What is a "fundamental type"?

Back to article view | Back to comp.std.c

Contents

  What is a "fundamental type"? Keith Thompson <kst-u@mib.org> - 2012-12-22 03:27 -0800
    Re: What is a "fundamental type"? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-22 08:21 -0800
      Re: What is a "fundamental type"? Keith Thompson <kst-u@mib.org> - 2012-12-22 12:29 -0800
        Re: What is a "fundamental type"? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-23 08:47 -0800
    Re: What is a "fundamental type"? Harald van Dijk <truedfx@gmail.com> - 2012-12-22 10:17 -0800

#1796 — What is a "fundamental type"?

N1370 6.2.8p4 says:

    Alignments are represented as values of the type size_t. Valid
    alignments include only those values returned by an
    _Alignof expression for fundamental types, plus an additional
    implementation-defined set of values, which may be empty. Every
    valid alignment value shall be a nonnegative integral power
    of two.

This and J.3.13 are the only occurrences of the phrase "fundamental
types" in the document; no definition is given.  It's related to
the defined term "fundamental alignment", but it's not clear how.

Given the context, the only consistent meaning I can think of is
that a "fundamental type" is one to which no alignment specifier
(the _Alignas keyword) is applied, or perhaps it's a type whose
alignment is a "fundamental alignment" (no stricter than _Alignof
(max_align_t)).  But "fundamental type" doesn't seem to me to be a
reasonable name for that concept.  Note that struct and array types
are not excluded; max_align_t is required to be an object type,
and needn't be scalar.

What exactly is a "fundamental type"?  Should it be defined, or
should 6.2.8p4 be rephrased to avoid the term?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [next] | [standalone]

#1797

Keith Thompson <kst-u@mib.org> writes:

> [snip]
>
> What exactly is a "fundamental type"?

AFAICS there is no definition for the term.  I took it to
mean a C type other than a 'derived type' (ie, not an array
type, or struct type, or pointer type, etc).  Probably it
also is supposed to imply no type qualifiers, although that
seems less important.  Also, I would guess that _Atomic on a
non-derived type is meant to be a "fundamental type" for
purposes of 6.2.8p4, but that is just a guess, I haven't
spent any time looking into that.

> Should it be defined, or should 6.2.8p4 be rephrased to
> avoid the term?

Yes, one or the other.

[toc] | [prev] | [next] | [standalone]

#1800

[This is a reply to followups from both Tim Rentsch and Harald van Dijk.]

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>> [snip]
>>
>> What exactly is a "fundamental type"?
>
> AFAICS there is no definition for the term.  I took it to
> mean a C type other than a 'derived type' (ie, not an array
> type, or struct type, or pointer type, etc).
[...]

Harald van Dijk <truedfx@gmail.com> writes:
> On Dec 22, 12:27 pm, Keith Thompson <ks...@mib.org> wrote:
>> N1370 6.2.8p4 says:
>>
>>     Alignments are represented as values of the type size_t. Valid
>>     alignments include only those values returned by an
>>     _Alignof expression for fundamental types, plus an additional
>>     implementation-defined set of values, which may be empty. Every
>>     valid alignment value shall be a nonnegative integral power
>>     of two.
>>
>> This and J.3.13 are the only occurrences of the phrase "fundamental
>> types" in the document; no definition is given.  It's related to
>> the defined term "fundamental alignment", but it's not clear how.
>
> I don't think it is. The text mostly comes from C++ (or was written
> for C and C++ at the same time), which says:
>
>> Alignments are represented as values of the type std::size_t. Valid
>> alignments include only those values returned by an alignof
>> expression for the fundamental types plus an additional
>> implementation-defined set of values, which may be empty. Every
>> alignment value shall be a non-negative integral power of two.
>
> C++'s "fundamental type" is very close to C's "basic type": for types
> that are part of both languages, the only type that is a "fundamental
> type" but not a "basic type" is void, which is not relevant here as
> alignof can only be applied to complete object types. I think it
> should be replaced by "basic type" in this text.
>
> A fundamental alignment is simply an alignment no stricter than that
> of max_align_t. It need not be the alignment of any fundamental type.

I'm not happy with either interpretation (which isn't to say that
it's incorrect).

Both your interpretations say that the "fundamental types" (ignoring
void) are a subset of the scalar types.

The use of the word "fundamental" in both 6.2.8p2:

    A *fundamental alignment* is represented by an alignment less
    than or equal to the greatest alignment supported by the
    implementation in all contexts, which is equal to _Alignof
    (max_align_t).

and 6.2.8p4:

    Alignments are represented as values of the type size_t. Valid
    alignments include only those values returned by an _Alignof
    expression for fundamental types, plus an additional
    implementation-defined set of values, which may be empty.

strongly suggests a relationship between "fundamental alignment" and
"fundamental type".  One might reasonably infer that the fundamental
alignments are the alignments of the fundamental types.

The alignment of max_align_t is explicitly stated to be a
"fundamental alignment", but max_align_t is only required to be
an *object* type.  For example, a conforming implementation could
have alignments no greater than 4 for all scalar types (or all
"fundamental types"), but max_align_t could be a struct type with
an alignment of 8.

So we have three disjoint subsets of permitted alignment values:

1. Alignments of fundamental/basic/scalar types.

2. Alignments greater than the above up to _Alignof (max_align_t).
   This set may be empty.

3. Alignments greater than _Alignof (max_align_t) which may be
   specified in an alignment clause.  This set may also be empty.

The "fundamental alignments" are subsets 1 and 2; the "extended
alignments" are subset 3.

IMHO, the distinction between subsets 1 and 2 is not particularly
useful.  I see the point in mentioning that some fundamental
alignments may exceed those of any scalar types, but it doesn't
really add any useful information -- and I find the way it's worded
confusing.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#1802

Keith Thompson <kst-u@mib.org> writes:

> [This is a reply to followups from both Tim Rentsch and Harald van Dijk.]
>
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> [snip]
>>>
>>> What exactly is a "fundamental type"?
>>
>> AFAICS there is no definition for the term.  I took it to
>> mean a C type other than a 'derived type' (ie, not an array
>> type, or struct type, or pointer type, etc).
> [...]
>
> Harald van Dijk <truedfx@gmail.com> writes:
>> On Dec 22, 12:27 pm, Keith Thompson <ks...@mib.org> wrote:
>>> N1370 6.2.8p4 says:
>>>
>>>     Alignments are represented as values of the type size_t. Valid
>>>     alignments include only those values returned by an
>>>     _Alignof expression for fundamental types, plus an additional
>>>     implementation-defined set of values, which may be empty. Every
>>>     valid alignment value shall be a nonnegative integral power
>>>     of two.
>>>
>>> This and J.3.13 are the only occurrences of the phrase "fundamental
>>> types" in the document; no definition is given.  It's related to
>>> the defined term "fundamental alignment", but it's not clear how.
>>
>> I don't think it is. The text mostly comes from C++ (or was written
>> for C and C++ at the same time), which says:
>>
>>> Alignments are represented as values of the type std::size_t. Valid
>>> alignments include only those values returned by an alignof
>>> expression for the fundamental types plus an additional
>>> implementation-defined set of values, which may be empty. Every
>>> alignment value shall be a non-negative integral power of two.
>>
>> C++'s "fundamental type" is very close to C's "basic type": for types
>> that are part of both languages, the only type that is a "fundamental
>> type" but not a "basic type" is void, which is not relevant here as
>> alignof can only be applied to complete object types. I think it
>> should be replaced by "basic type" in this text.
>>
>> A fundamental alignment is simply an alignment no stricter than that
>> of max_align_t. It need not be the alignment of any fundamental type.
>
> I'm not happy with either interpretation (which isn't to say that
> it's incorrect).
>
> Both your interpretations say that the "fundamental types" (ignoring
> void) are a subset of the scalar types.
>
> The use of the word "fundamental" in both 6.2.8p2:
>
>     A *fundamental alignment* is represented by an alignment less
>     than or equal to the greatest alignment supported by the
>     implementation in all contexts, which is equal to _Alignof
>     (max_align_t).
>
> and 6.2.8p4:
>
>     Alignments are represented as values of the type size_t. Valid
>     alignments include only those values returned by an _Alignof
>     expression for fundamental types, plus an additional
>     implementation-defined set of values, which may be empty.
>
> strongly suggests a relationship between "fundamental alignment" and
> "fundamental type".  One might reasonably infer that the fundamental
> alignments are the alignments of the fundamental types.
>
> The alignment of max_align_t is explicitly stated to be a
> "fundamental alignment", but max_align_t is only required to be
> an *object* type.  For example, a conforming implementation could
> have alignments no greater than 4 for all scalar types (or all
> "fundamental types"), but max_align_t could be a struct type with
> an alignment of 8.
>
> So we have three disjoint subsets of permitted alignment values:
>
> 1. Alignments of fundamental/basic/scalar types.
>
> 2. Alignments greater than the above up to _Alignof (max_align_t).
>    This set may be empty.
>
> 3. Alignments greater than _Alignof (max_align_t) which may be
>    specified in an alignment clause.  This set may also be empty.
>
> The "fundamental alignments" are subsets 1 and 2; the "extended
> alignments" are subset 3.
>
> IMHO, the distinction between subsets 1 and 2 is not particularly
> useful.  I see the point in mentioning that some fundamental
> alignments may exceed those of any scalar types, but it doesn't
> really add any useful information -- and I find the way it's worded
> confusing.

Excellently said.

In retrospect, it's clear my initial impression about which
types fall under the label of "fundamental types" is simply
wrong.

Looking into the alignment stuff more carefully, ISTM that
it is not very well thought out.  The basic ideas seem
alright, but some of the specifics are either fuzzy or
not expressed clearly (or perhaps both).  At least that
is my impression.

Having said that, I now will venture the opinion that a
fundamental type is any type (presumably an object type,
but that is a minor concern) constructed using only
ordinary methods of type synthesis, or more specifically
types that are not affected by any alignment specifiers.
So all of the (object) types from C99, plus (I am guessing)
atomic versions of those types for those implementations
that support atomic types (perhaps recursively so structs
can have atomic members, etc), but not depending on any
_Alignas specifiers, make up the "fundamental types" of
section 6.2.8.

[toc] | [prev] | [next] | [standalone]

#1799

On Dec 22, 12:27 pm, Keith Thompson <ks...@mib.org> wrote:
> N1370 6.2.8p4 says:
>
>     Alignments are represented as values of the type size_t. Valid
>     alignments include only those values returned by an
>     _Alignof expression for fundamental types, plus an additional
>     implementation-defined set of values, which may be empty. Every
>     valid alignment value shall be a nonnegative integral power
>     of two.
>
> This and J.3.13 are the only occurrences of the phrase "fundamental
> types" in the document; no definition is given.  It's related to
> the defined term "fundamental alignment", but it's not clear how.

I don't think it is. The text mostly comes from C++ (or was written
for C and C++ at the same time), which says:

> Alignments are represented as values of the type std::size_t. Valid
> alignments include only those values returned by an alignof expression
> for the fundamental types plus an additional implementation-defined
> set of values, which may be empty. Every alignment value shall be a
> non-negative integral power of two.

C++'s "fundamental type" is very close to C's "basic type": for types
that are part of both languages, the only type that is a "fundamental
type" but not a "basic type" is void, which is not relevant here as
alignof can only be applied to complete object types. I think it
should
be replaced by "basic type" in this text.

A fundamental alignment is simply an alignment no stricter than that
of max_align_t. It need not be the alignment of any fundamental type.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.std.c

csiph-web