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

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

Types in C

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

Contents

  Types in C jacob navia <jacob@spamsink.net> - 2011-05-22 21:29 +0200
    Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-22 12:48 -0700
    Re: Types in C Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-05-30 22:42 +0200
      Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-30 17:45 -0500
        Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-31 08:47 -0700
          Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-31 13:54 -0400
        Re: Types in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-31 22:38 -0700
          Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-06-01 07:22 -0500
            Re: Types in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-01 12:13 -0700
      Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-31 00:16 +0200
        Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-30 18:30 -0500
          Re: Types in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-31 22:43 -0700
            Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-06-01 07:41 -0500
              Re: Types in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-01 12:23 -0700
        Re: Types in C Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-06-02 22:44 +0200
          Re: Types in C jacob navia <jacob@spamsink.net> - 2011-06-02 22:49 +0200
            Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-06-02 15:26 -0700

#319 — Types in C

Hi

I am updating my tutorial of C, and I have added a section of type
classification. Please tell me if I forgot something or said
something wrong if possible.

Thanks in advance for your help


A C type can be either a function type, an incomplete type or an object
type. Function types can be either fully specified, i.e. we have a
prototype available, or partially specified with missing arguments but
a known return value. The function type "implicit int function"  with
return value and arguments unknown, has been declared obsolete in C99.

Incomplete types are unspecified and it is assumed that they will be
specified elsewhere, except for the void type that is an incomplete
type that can't be further specified.

Object types can be either scalar or composite types. Composite types
are built from the scalar types: structures, unions and arrays. Scalar
types are of two kinds: arithmetic or pointer types. Pointer types can
point to scalar or composite types, to functions or to incomplete types.

Arithmetic types have two kinds: integer types and floating types. The 
integer types are either standard integers, bit fields or enumerations.

The standard integer types are boolean, char, short, int, long and long
long, all with signed or unsigned types, except the boolean type
that hasn't any sign but is not an unsigned type.

Floating types are either real or complex, with both of them appearing 
in three flavors: float, double and long double.

[toc] | [next] | [standalone]

#320

jacob navia <jacob@spamsink.net> writes:
> I am updating my tutorial of C, and I have added a section of type
> classification. Please tell me if I forgot something or said
> something wrong if possible.
>
> Thanks in advance for your help
>
>
> A C type can be either a function type, an incomplete type or an object
> type. Function types can be either fully specified, i.e. we have a
> prototype available, or partially specified with missing arguments but
> a known return value. The function type "implicit int function"  with
> return value and arguments unknown, has been declared obsolete in C99.

In C90, "implicit int function" isn't a distinct type.
    foo(void);
and
    int foo(void);
are merely two different ways of expressing exactly the same thing.
The return type isn't unknown, it's int.

> Incomplete types are unspecified and it is assumed that they will be
> specified elsewhere, except for the void type that is an incomplete
> type that can't be further specified.
>
> Object types can be either scalar or composite types. Composite types
> are built from the scalar types: structures, unions and arrays. Scalar
> types are of two kinds: arithmetic or pointer types. Pointer types can
> point to scalar or composite types, to functions or to incomplete types.

The phrase "composite type" has a very different meaning; see C99 6.2.7.

The standard refers to array and structure types (but not union types)
as "aggregate types".  It doesn't seem to have a term that covers
arrays, structures and unions (and I'd be very hesitant in this kind of
tutorial to invent terms that aren't in the standard).

> Arithmetic types have two kinds: integer types and floating types. The 
> integer types are either standard integers, bit fields or enumerations.
>
> The standard integer types are boolean, char, short, int, long and long
> long, all with signed or unsigned types, except the boolean type
> that hasn't any sign but is not an unsigned type.

You didn't mention extended integer types.  I don't know whether you
want to.

> Floating types are either real or complex, with both of them appearing 
> in three flavors: float, double and long double.

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

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

#358

jacob navia wrote:
>[...]
> A C type can be either a function type, an incomplete type or an object
> type.

Recently the Committee agreed with Clive Feather that completeness is a 
scoped property of object types (there are no incomplete function types, 
after all), and the latest C1X draft says the following under 6.2.5 
("Types"):

# Types are partitioned into object types (types that describe objects)
# and function types (types that describe functions). At various points
# within a translation unit an object type may be incomplete (lacking
# sufficient information to determine the size of objects of that type)
# or complete (having sufficient information).

I, too, believe it is a clearer way of describing how the C type system 
works.  (For Clive's rationale, see the WG14 document N1439).
-- 
Marcin Grzegorczyk

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

#359

On 5/30/2011 3:42 PM, Marcin Grzegorczyk wrote:
> jacob navia wrote:
>> [...]
>> A C type can be either a function type, an incomplete type or an object
>> type.
>
> Recently the Committee agreed with Clive Feather that completeness is a
> scoped property of object types (there are no incomplete function types,
> after all), and the latest C1X draft says the following under 6.2.5
> ("Types"):
>
> # Types are partitioned into object types (types that describe objects)
> # and function types (types that describe functions). At various points
> # within a translation unit an object type may be incomplete (lacking
> # sufficient information to determine the size of objects of that type)
> # or complete (having sufficient information).
>
> I, too, believe it is a clearer way of describing how the C type system
> works. (For Clive's rationale, see the WG14 document N1439).

Though I think the obsolescence under the N1494's 6.11.6p1 is 
intuitively akin to an "incomplete function type," though such a term is 
not defined in a standard sense, perhaps.

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

#362

Shao Miller <sha0.miller@gmail.com> writes:
> On 5/30/2011 3:42 PM, Marcin Grzegorczyk wrote:
>> jacob navia wrote:
>>> [...]
>>> A C type can be either a function type, an incomplete type or an object
>>> type.
>>
>> Recently the Committee agreed with Clive Feather that completeness is a
>> scoped property of object types (there are no incomplete function types,
>> after all), and the latest C1X draft says the following under 6.2.5
>> ("Types"):
>>
>> # Types are partitioned into object types (types that describe objects)
>> # and function types (types that describe functions). At various points
>> # within a translation unit an object type may be incomplete (lacking
>> # sufficient information to determine the size of objects of that type)
>> # or complete (having sufficient information).
>>
>> I, too, believe it is a clearer way of describing how the C type system
>> works. (For Clive's rationale, see the WG14 document N1439).
>
> Though I think the obsolescence under the N1494's 6.11.6p1 is 
> intuitively akin to an "incomplete function type," though such a term is 
> not defined in a standard sense, perhaps.

    For those who don't have a copy of N1494:

    6.11.6 Function declarators

    The use of function declarators with empty parentheses (not
    prototype-format parameter type declarators) is an obsolescent
    feature.

I don't see much resemblance between that and incomplete type.
The obsolecence itself is irrelevant; until they're removed from
the language (and when is the committee finally going to get around
to that?), they're a required language feature.

A function type declared without a prototype is fully usable; you can
declare a pointer to it and use such a pointer in a function call.
I suppose it's "incomplete" in the sense that some information is
missing, but it's not the same kind of incompleteness that applies
to void.

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

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

#363

On 5/31/2011 11:47, Keith Thompson wrote:
> Shao Miller<sha0.miller@gmail.com>  writes:
>> On 5/30/2011 3:42 PM, Marcin Grzegorczyk wrote:
>>> jacob navia wrote:
>>>> [...]
>>>> A C type can be either a function type, an incomplete type or an object
>>>> type.
>>>
>>> Recently the Committee agreed with Clive Feather that completeness is a
>>> scoped property of object types (there are no incomplete function types,
>>> after all), and the latest C1X draft says the following under 6.2.5
>>> ("Types"):
>>>
>>> # Types are partitioned into object types (types that describe objects)
>>> # and function types (types that describe functions). At various points
>>> # within a translation unit an object type may be incomplete (lacking
>>> # sufficient information to determine the size of objects of that type)
>>> # or complete (having sufficient information).
>>>
>>> I, too, believe it is a clearer way of describing how the C type system
>>> works. (For Clive's rationale, see the WG14 document N1439).
>>
>> Though I think the obsolescence under the N1494's 6.11.6p1 is
>> intuitively akin to an "incomplete function type," though such a term is
>> not defined in a standard sense, perhaps.
>
>      For those who don't have a copy of N1494:
>
>      6.11.6 Function declarators
>
>      The use of function declarators with empty parentheses (not
>      prototype-format parameter type declarators) is an obsolescent
>      feature.
>

In the future, I ought to include the point, given similar brevity.  Thanks.

> I don't see much resemblance between that and incomplete type.
> The obsolecence itself is irrelevant; until they're removed from
> the language (and when is the committee finally going to get around
> to that?), they're a required language feature.

Heheh.

>
> A function type declared without a prototype is fully usable; you can
> declare a pointer to it and use such a pointer in a function call.
> I suppose it's "incomplete" in the sense that some information is
> missing, but it's not the same kind of incompleteness that applies
> to void.
>

I was thinking of precisely the likeness you point out.  To further 
illustrate:

   #define NO_WAY 0

   /*** Types */
   /* Incomplete */
   struct s_foo;

   /* Completed */
   struct s_foo {
       int x;
     };

   /* Illegal */
   #if NO_WAY
   struct s_foo {
       int x;
       double y;
     };
   #endif

   /* Incomplete, cannot be completed */
   typedef int a_bar[];

   /* Complete, compatible with a_bar */
   typedef int a_bar2[10];

   /* Different size specifier (element count) */
   typedef int a_bar3[20];

   /* "Incomplete", cannot be "completed" */
   typedef void f_baz();

   /* "Complete" and compatible with f_baz */
   typedef void f_baz2(int);

   /* Different parameter specification */
   typedef void f_baz3(double);

   /*** Objects */
   /* "Partial" */
   a_bar obj_bar;

   /* "Complete" */
   a_bar2 obj_bar;

   /* Illegal */
   #if NO_WAY
   a_bar3 obj_bar;
   #endif

   /*** Functions */
   /* "Partial" */
   f_baz func_baz;

   /* "Complete" */
   f_baz2 func_baz;

   /* Illegal */
   #if NO_WAY
   f_baz3 func_baz;
   #endif

   int main(void) {
       return 0;
     }

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

#368

Shao Miller <sha0.miller@gmail.com> writes:

> On 5/30/2011 3:42 PM, Marcin Grzegorczyk wrote:
>> jacob navia wrote:
>>> [...]
>>> A C type can be either a function type, an incomplete type or an object
>>> type.
>>
>> Recently the Committee agreed with Clive Feather that completeness is a
>> scoped property of object types (there are no incomplete function types,
>> after all), and the latest C1X draft says the following under 6.2.5
>> ("Types"):
>>
>> # Types are partitioned into object types (types that describe objects)
>> # and function types (types that describe functions). At various points
>> # within a translation unit an object type may be incomplete (lacking
>> # sufficient information to determine the size of objects of that type)
>> # or complete (having sufficient information).
>>
>> I, too, believe it is a clearer way of describing how the C type system
>> works. (For Clive's rationale, see the WG14 document N1439).
>
> Though I think the obsolescence under the N1494's 6.11.6p1 is
> intuitively akin to an "incomplete function type," though such a term
> is not defined in a standard sense, perhaps.

IMO this notion is more misleading than helpful.

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

#375

On 6/1/2011 12:38 AM, Tim Rentsch wrote:
> Shao Miller<sha0.miller@gmail.com>  writes:
>
>> On 5/30/2011 3:42 PM, Marcin Grzegorczyk wrote:
>>> jacob navia wrote:
>>>> [...]
>>>> A C type can be either a function type, an incomplete type or an object
>>>> type.
>>>
>>> Recently the Committee agreed with Clive Feather that completeness is a
>>> scoped property of object types (there are no incomplete function types,
>>> after all), and the latest C1X draft says the following under 6.2.5
>>> ("Types"):
>>>
>>> # Types are partitioned into object types (types that describe objects)
>>> # and function types (types that describe functions). At various points
>>> # within a translation unit an object type may be incomplete (lacking
>>> # sufficient information to determine the size of objects of that type)
>>> # or complete (having sufficient information).
>>>
>>> I, too, believe it is a clearer way of describing how the C type system
>>> works. (For Clive's rationale, see the WG14 document N1439).
>>
>> Though I think the obsolescence under the N1494's 6.11.6p1 is
>> intuitively akin to an "incomplete function type," though such a term
>> is not defined in a standard sense, perhaps.
>
> IMO this notion is more misleading than helpful.

I didn't mean to suggest that the original poster teaches this notion in 
his tutorial.  But a function type lacking information about its 
parameters certainly seems "incomplete;" it's lacking information.  See 
the code example elsethread for a simple illustration.

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

#379

Shao Miller <sha0.miller@gmail.com> writes:

> On 6/1/2011 12:38 AM, Tim Rentsch wrote:
>> Shao Miller<sha0.miller@gmail.com>  writes:
>>
>>> On 5/30/2011 3:42 PM, Marcin Grzegorczyk wrote:
>>>> jacob navia wrote:
>>>>> [...]
>>>>> A C type can be either a function type, an incomplete type or an object
>>>>> type.
>>>>
>>>> Recently the Committee agreed with Clive Feather that completeness is a
>>>> scoped property of object types (there are no incomplete function types,
>>>> after all), and the latest C1X draft says the following under 6.2.5
>>>> ("Types"):
>>>>
>>>> # Types are partitioned into object types (types that describe objects)
>>>> # and function types (types that describe functions). At various points
>>>> # within a translation unit an object type may be incomplete (lacking
>>>> # sufficient information to determine the size of objects of that type)
>>>> # or complete (having sufficient information).
>>>>
>>>> I, too, believe it is a clearer way of describing how the C type system
>>>> works. (For Clive's rationale, see the WG14 document N1439).
>>>
>>> Though I think the obsolescence under the N1494's 6.11.6p1 is
>>> intuitively akin to an "incomplete function type," though such a term
>>> is not defined in a standard sense, perhaps.
>>
>> IMO this notion is more misleading than helpful.
>
> I didn't mean to suggest that the original poster teaches this notion
> in his tutorial.  But a function type lacking information about its
> parameters certainly seems "incomplete;" it's lacking information.
> See the code example elsethread for a simple illustration.

I already understood the proposed analogy;  I just
don't think it merits any further consideration.

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

#360

Le 30/05/11 22:42, Marcin Grzegorczyk a écrit :
> jacob navia wrote:
>> [...]
>> A C type can be either a function type, an incomplete type or an object
>> type.
>
> Recently the Committee agreed with Clive Feather that completeness is a
> scoped property of object types (there are no incomplete function types,
> after all), and the latest C1X draft says the following under 6.2.5
> ("Types"):
>
> # Types are partitioned into object types (types that describe objects)
> # and function types (types that describe functions). At various points
> # within a translation unit an object type may be incomplete (lacking
> # sufficient information to determine the size of objects of that type)
> # or complete (having sufficient information).
>
> I, too, believe it is a clearer way of describing how the C type system
> works. (For Clive's rationale, see the WG14 document N1439).

After reading N1439 I would tend to agree with what it says but
where should go the void type?

It is void an object type?

What was easy to understand in the original classification is that void
had a natural neighborhood: incomplete types.

I deduce (indirectly) that Mr Cleaver thinks void is an object type
because he says:

6.3.2.1#1
Change “an object or incomplete type other than void” to “an object
type other than void”.

If "an object type other than void" is accepted it would mean that
void is an object type.

The problem is that N1429 is difficult to read because it only
refers to what should be patched and doesn't display the patched
text.

In any case thanks a lot for taking the time to answer.

jacob

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

#361

On 5/30/2011 5:16 PM, jacob navia wrote:
> Le 30/05/11 22:42, Marcin Grzegorczyk a écrit :
>> jacob navia wrote:
>>> [...]
>>> A C type can be either a function type, an incomplete type or an object
>>> type.
>>
>> Recently the Committee agreed with Clive Feather that completeness is a
>> scoped property of object types (there are no incomplete function types,
>> after all), and the latest C1X draft says the following under 6.2.5
>> ("Types"):
>>
>> # Types are partitioned into object types (types that describe objects)
>> # and function types (types that describe functions). At various points
>> # within a translation unit an object type may be incomplete (lacking
>> # sufficient information to determine the size of objects of that type)
>> # or complete (having sufficient information).
>>
>> I, too, believe it is a clearer way of describing how the C type system
>> works. (For Clive's rationale, see the WG14 document N1439).
>
> After reading N1439 I would tend to agree with what it says but
> where should go the void type?
>
> It is void an object type?
>

Yes.  But it can never be completed.

> What was easy to understand in the original classification is that void
> had a natural neighborhood: incomplete types.
>
> I deduce (indirectly) that Mr Cleaver

(Nit-pick: Mr. Clive Feather.)

> thinks void is an object type
> because he says:
>
> 6.3.2.1#1
> Change “an object or incomplete type other than void” to “an object
> type other than void”.
>
> If "an object type other than void" is accepted it would mean that
> void is an object type.
>

Agreed.

> The problem is that N1429 is difficult to read because it only
> refers to what should be patched and doesn't display the patched
> text.
>
> In any case thanks a lot for taking the time to answer.

In the N1494 draft, we have 6.2.5p19:

   "The void type comprises an empty set of values; it is an incomplete 
object type that cannot be completed."

Similarly:

   typedef char a_incomplete[];

could never be completed, if I'm not mistaken.

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

#369

Shao Miller <sha0.miller@gmail.com> writes:

[snip]
>
> In the N1494 draft, we have 6.2.5p19:
>
>   "The void type comprises an empty set of values; it is an incomplete
> object type that cannot be completed."
>
> Similarly:
>
>   typedef char a_incomplete[];
>
> could never be completed, if I'm not mistaken.

Only because there is no way to refer to type in
question, not for any sort of fundamental reason.
The two cases aren't analogous at all.

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

#376

On 6/1/2011 12:43 AM, Tim Rentsch wrote:
> Shao Miller<sha0.miller@gmail.com>  writes:
>
> [snip]
>>
>> In the N1494 draft, we have 6.2.5p19:
>>
>>    "The void type comprises an empty set of values; it is an incomplete
>> object type that cannot be completed."
>>
>> Similarly:
>>
>>    typedef char a_incomplete[];
>>
>> could never be completed, if I'm not mistaken.
>
> Only because there is no way to refer to type in
> question, not for any sort of fundamental reason.
> The two cases aren't analogous at all.

The original poster seemed, to me, to be struggling with the idea that 
an object type can be incomplete and complete at different times, but 
that the previous status of 'void' as an "incomplete type" mightn't 
quite fit with the new status of "object type" ("incomplete object 
type," in particular).  This was simply an example of another incomplete 
object type which forever carries that status, you've agreed.

If I'd typed, "you can substitute 'a_incomplete' wherever you see 'void' 
in the Standard," then we'd have a bigger problem. :)

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

#380

Shao Miller <sha0.miller@gmail.com> writes:

> On 6/1/2011 12:43 AM, Tim Rentsch wrote:
>> Shao Miller<sha0.miller@gmail.com>  writes:
>>
>> [snip]
>>>
>>> In the N1494 draft, we have 6.2.5p19:
>>>
>>>    "The void type comprises an empty set of values; it is an incomplete
>>> object type that cannot be completed."
>>>
>>> Similarly:
>>>
>>>    typedef char a_incomplete[];
>>>
>>> could never be completed, if I'm not mistaken.
>>
>> Only because there is no way to refer to type in
>> question, not for any sort of fundamental reason.
>> The two cases aren't analogous at all.
>
> The original poster seemed, to me, to be struggling with the idea that
> an object type can be incomplete and complete at different times, but
> that the previous status of 'void' as an "incomplete type" mightn't
> quite fit with the new status of "object type" ("incomplete object
> type," in particular).  This was simply an example of another
> incomplete object type which forever carries that status, you've
> agreed.

No, I haven't.  The two cases are not the same.

In fact the case with a typedef of an incomplete array
type could be made complete, by providing an extension
(eg, using _Pragma or some such) that allows an existing
type to be decorated with additional information.  So saying
the typedef'ed array type can never be completed is wrong.
And that result is fundamentally different from void.

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

#389

jacob navia wrote:
> Le 30/05/11 22:42, Marcin Grzegorczyk a écrit :
>> jacob navia wrote:
>>> [...]
>>> A C type can be either a function type, an incomplete type or an object
>>> type.
>>
>> Recently the Committee agreed with Clive Feather that completeness is a
>> scoped property of object types (there are no incomplete function types,
>> after all), and the latest C1X draft says the following under 6.2.5
>> ("Types"):
[quotation snipped]
>> I, too, believe it is a clearer way of describing how the C type system
>> works. (For Clive's rationale, see the WG14 document N1439).
>
> After reading N1439 I would tend to agree with what it says but
> where should go the void type?
>
> It is void an object type?

Yes, void belongs to object types, even if it might seem weird at first.

Consider how the void type is used:
* As a function return type.  Function return types are object types.
* As a function parameter type (with special constraints).  Function 
parameter types are object types, too.
* As a pointed-to type.  There are pointers to object types and pointers 
to function types; `void*` is compatible only with the former.

[snip]
> The problem is that N1429 is difficult to read because it only
> refers to what should be patched and doesn't display the patched
> text.

I brought N1429 only for the rationale.  (The latest C1X draft is N1569 
/ N1570 (without / with diff marks, respectively).)
-- 
Marcin Grzegorczyk

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

#390

Le 02/06/11 22:44, Marcin Grzegorczyk a écrit :
> jacob navia wrote:
>> Le 30/05/11 22:42, Marcin Grzegorczyk a écrit :
>>> jacob navia wrote:
>> After reading N1439 I would tend to agree with what it says but
>> where should go the void type?
>>
>> It is void an object type?
>
> Yes, void belongs to object types, even if it might seem weird at first.
>

Well, YES...

It seems weird to me, I wonder how the readers of the tutorial will
react.

In any case I will update the tutorial to reflect the current
thinking of the committee.

> Consider how the void type is used:
> * As a function return type. Function return types are object types.
> * As a function parameter type (with special constraints). Function
> parameter types are object types, too.
> * As a pointed-to type. There are pointers to object types and pointers
> to function types; `void*` is compatible only with the former.
>
> [snip]
>> The problem is that N1429 is difficult to read because it only
>> refers to what should be patched and doesn't display the patched
>> text.
>
> I brought N1429 only for the rationale. (The latest C1X draft is N1569 /
> N1570 (without / with diff marks, respectively).)

OK. Thanks.

jacob

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

#391

jacob navia <jacob@spamsink.net> writes:
> Le 02/06/11 22:44, Marcin Grzegorczyk a écrit :
>> jacob navia wrote:
>>> Le 30/05/11 22:42, Marcin Grzegorczyk a écrit :
>>>> jacob navia wrote:
>>> After reading N1439 I would tend to agree with what it says but
>>> where should go the void type?
>>>
>>> It is void an object type?
>>
>> Yes, void belongs to object types, even if it might seem weird at first.
>>
>
> Well, YES...
>
> It seems weird to me, I wonder how the readers of the tutorial will
> react.
>
> In any case I will update the tutorial to reflect the current
> thinking of the committee.
[...]

That's up to you, of course, but in the current standard void is
not an object type.  It's an incomplete type, and incomplete types
are disjoint from object types.

C201X has no official standing yet, and there are no conforming
implementations.

Are you writing a C99 tutorial or a C201X tutorial?  If the latter,
I suggest making it clear that you're referring to a future version
of the language.

Or you might consider writing both, using something similar to
#ifdef to let you generate either version (depending on what tool
you're using to write and publish the tutorial).

(In this particular case, it's just a different way of describing the
same thing.)

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

[toc] | [prev] | [standalone]

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

csiph-web