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

Groups > comp.lang.c > #69953 > unrolled thread

Can "enum" be forced to a certain "bitness"?

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

Contents

  Can "enum" be forced to a certain "bitness"? Ken Brody <kenbrody@spamcop.net> - 2015-09-08 15:07 -0400
    Re: Can "enum" be forced to a certain "bitness"? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-08 20:17 +0100
      Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-08 12:36 -0700
        Re: Can "enum" be forced to a certain "bitness"? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-08 22:52 +0100
        Re: Can "enum" be forced to a certain "bitness"? Ken Brody <kenbrody@spamcop.net> - 2015-09-09 11:40 -0400
      Re: Can "enum" be forced to a certain "bitness"? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 14:57 -0700
        Re: Can "enum" be forced to a certain "bitness"? Bartc <bc@freeuk.com> - 2015-09-08 23:10 +0100
          Re: Can "enum" be forced to a certain "bitness"? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 15:15 -0700
            Re: Can "enum" be forced to a certain "bitness"? Ian Collins <ian-news@hotmail.com> - 2015-09-09 10:35 +1200
              Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-09 11:07 +0200
                Re: Can "enum" be forced to a certain "bitness"? Bartc <bc@freeuk.com> - 2015-09-09 12:36 +0100
                  Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-09 13:46 +0200
                    Re: Can "enum" be forced to a certain "bitness"? Ian Collins <ian-news@hotmail.com> - 2015-09-11 11:32 +1200
                      Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-10 17:39 -0700
                        Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-11 09:03 +0200
                          Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-11 11:33 -0700
                        Re: Can "enum" be forced to a certain "bitness"? Ian Collins <ian-news@hotmail.com> - 2015-09-11 21:24 +1200
                          Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-11 11:38 +0200
                            Re: Can "enum" be forced to a certain "bitness"? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-11 10:40 +0100
                              Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-11 12:51 +0200
                                Re: Can "enum" be forced to a certain "bitness"? Les Cargill <lcargill99@comcast.com> - 2015-09-11 12:21 -0500
                            Re: Can "enum" be forced to a certain "bitness"? supercat@casperkitty.com - 2015-09-11 15:03 -0700
                              Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-12 15:01 +0200
                      Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-11 09:23 +0200
                  Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-10 10:06 +0200
                  Re: Can "enum" be forced to a certain "bitness"? David Kleinecke <dkleinecke@gmail.com> - 2015-09-15 17:55 -0700
          Re: Can "enum" be forced to a certain "bitness"? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-09-08 18:36 -0400
            Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-08 16:14 -0700
              Re: Can "enum" be forced to a certain "bitness"? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-09-08 19:49 -0400
                Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-08 17:20 -0700
          Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-08 15:48 -0700
            Re: Can "enum" be forced to a certain "bitness"? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 16:03 -0700
              Re: Can "enum" be forced to a certain "bitness"? Ian Collins <ian-news@hotmail.com> - 2015-09-09 11:16 +1200
                Re: Can "enum" be forced to a certain "bitness"? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 16:18 -0700
                  Re: Can "enum" be forced to a certain "bitness"? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 16:19 -0700
                    Re: Can "enum" be forced to a certain "bitness"? Ian Collins <ian-news@hotmail.com> - 2015-09-09 11:42 +1200
                      Re: Can "enum" be forced to a certain "bitness"? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-09 00:52 +0100
                        Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-09 13:28 +0200
                          Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-09 10:56 -0700
                            Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-09 22:17 +0200
                      Re: Can "enum" be forced to a certain "bitness"? Philip Lantz <prl@canterey.us> - 2015-09-08 22:06 -0700
                        Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-08 23:14 -0700
          Re: Can "enum" be forced to a certain "bitness"? supercat@casperkitty.com - 2015-09-09 16:10 -0700
        Re: Can "enum" be forced to a certain "bitness"? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-09 00:42 +0100
          Re: Can "enum" be forced to a certain "bitness"? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 16:55 -0700
            Re: Can "enum" be forced to a certain "bitness"? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-09 01:31 +0100
              Re: Can "enum" be forced to a certain "bitness"? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 17:51 -0700
        Re: Can "enum" be forced to a certain "bitness"? Les Cargill <lcargill99@comcast.com> - 2015-09-08 22:53 -0500
          Re: Can "enum" be forced to a certain "bitness"? Bartc <bc@freeuk.com> - 2015-09-09 10:00 +0100
            Re: Can "enum" be forced to a certain "bitness"? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-09 11:27 +0100
              Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-09 13:31 +0200
              Re: Can "enum" be forced to a certain "bitness"? Les Cargill <lcargill99@comcast.com> - 2015-09-09 18:32 -0500
                Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-09 17:15 -0700
            Re: Can "enum" be forced to a certain "bitness"? Les Cargill <lcargill99@comcast.com> - 2015-09-09 18:29 -0500
              Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-09 17:10 -0700
                Re: Can "enum" be forced to a certain "bitness"? Les Cargill <lcargill99@comcast.com> - 2015-09-09 22:27 -0500
                  Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-09 21:09 -0700
                    Re: Can "enum" be forced to a certain "bitness"? Les Cargill <lcargill99@comcast.com> - 2015-09-10 01:54 -0500
                      Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-10 10:57 -0700
                  Re: Can "enum" be forced to a certain "bitness"? James Kuyper <jameskuyper@verizon.net> - 2015-09-10 00:21 -0400
                    Re: Can "enum" be forced to a certain "bitness"? Les Cargill <lcargill99@comcast.com> - 2015-09-10 02:00 -0500
                      Re: Can "enum" be forced to a certain "bitness"? James Kuyper <jameskuyper@verizon.net> - 2015-09-10 09:32 -0400
        Re: Can "enum" be forced to a certain "bitness"? fir <profesor.fir@gmail.com> - 2015-09-09 08:19 -0700
          Re: Can "enum" be forced to a certain "bitness"? fir <profesor.fir@gmail.com> - 2015-09-09 08:43 -0700
          Re: Can "enum" be forced to a certain "bitness"? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 13:05 -0700
            Re: Can "enum" be forced to a certain "bitness"? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 13:10 -0700
              Re: Can "enum" be forced to a certain "bitness"? fir <profesor.fir@gmail.com> - 2015-09-10 00:47 -0700
                Re: Can "enum" be forced to a certain "bitness"? fir <profesor.fir@gmail.com> - 2015-09-10 01:05 -0700
                  Re: Can "enum" be forced to a certain "bitness"? fir <profesor.fir@gmail.com> - 2015-09-10 02:04 -0700
                  Re: Can "enum" be forced to a certain "bitness"? Bartc <bc@freeuk.com> - 2015-09-10 10:30 +0100
                    Re: Can "enum" be forced to a certain "bitness"? fir <profesor.fir@gmail.com> - 2015-09-10 06:33 -0700
                      Re: Can "enum" be forced to a certain "bitness"? fir <profesor.fir@gmail.com> - 2015-09-10 06:43 -0700
                        Re: Can "enum" be forced to a certain "bitness"? fir <profesor.fir@gmail.com> - 2015-09-15 15:22 -0700
                Re: Can "enum" be forced to a certain "bitness"? fir <profesor.fir@gmail.com> - 2015-09-10 01:35 -0700
    Re: Can "enum" be forced to a certain "bitness"? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-08 15:38 -0400
      Re: Can "enum" be forced to a certain "bitness"? Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-09 10:52 -0700
        Re: Can "enum" be forced to a certain "bitness"? David Thompson <dave.thompson2@verizon.net> - 2015-09-20 18:35 -0400
          Re: Can "enum" be forced to a certain "bitness"? Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 16:30 -0700
          Re: Can "enum" be forced to a certain "bitness"? Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 16:51 -0700
    Re: Can "enum" be forced to a certain "bitness"? James Kuyper <jameskuyper@verizon.net> - 2015-09-08 15:50 -0400
    Re: Can "enum" be forced to a certain "bitness"? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-08 20:25 +0000
    Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-08 23:09 +0200

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#70023

Ian Collins wrote:
> 
> Rick C. Hodgin wrote:
> >  Rick C. Hodgin wrote:
> >> What is 0 in this case?
> >>
> >>       char c = 0;
> >>
> >> Is 0 an integer?  Or is it a char?
> >
> > Should read:  "Is 0 an int?..."
> 
> I'm not much of a language lawyer, but I would say that according to the 
> rules of C99 6.4.4.1, it is an integer constant.

It is also a null pointer constant.

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

#70024

Philip Lantz <prl@canterey.us> writes:
> Ian Collins wrote:
>> 
>> Rick C. Hodgin wrote:
>> >  Rick C. Hodgin wrote:
>> >> What is 0 in this case?
>> >>
>> >>       char c = 0;
>> >>
>> >> Is 0 an integer?  Or is it a char?
>> >
>> > Should read:  "Is 0 an int?..."
>> 
>> I'm not much of a language lawyer, but I would say that according to the 
>> rules of C99 6.4.4.1, it is an integer constant.
>
> It is also a null pointer constant.

And it's of type int.

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

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

#70082

On Tuesday, September 8, 2015 at 5:11:11 PM UTC-5, Bart wrote:
> On 08/09/2015 22:57, Rick C. Hodgin wrote:
> > This is a fundamental flaw in the language.
> 
> I don't agree.

The lack of a compiler-independent means to specify how information should
be stored, and when computations should be performed using signed or
unsigned math, are major weaknesses in a language which is supposed to be
used for systems-level programming.  The lack of a means of forcing the
storage format for "enum" is less of a problem than the lack of a portable
and efficient means of declaring a type which will e.g. behave the way that
"unsigned int" works on a 16-bit machine, but both are aspects of a the same
fundamental problem: C was developed for the purpose of maximizing the number
of machines that could handle the language, rather than making it possible
to use one piece of code on many different machines.

I think that it should be possible and useful to add some new standard types
and macros to the language in a way that compilers could be upgraded to
comply with the new standard merely by bundling some new header files which
included support for things the compiler inherently does, and code using the
new types would be able to run on those compilers which can meet its
requirements and fail on those that don't; I don't know of any efforts in that
regard, however.

As an example, if I were in charge of the language I'd add types "uwrap16_t",
"uwrap32_t", etc. with the rule that a "uwrap16_t" should be a type which
would behave essentially the way an "unsigned int" would behave on a system
where "unsigned int" is 16 bits [and likewise for `uwrap32_t`, etc.].  Almost
any existing compiler where "int" is 16 bits and "long" is 32 bits could
support such a type merely by adding it to a standard header, and 32-bit
compilers could support "uwrap32_t" [but not "uwrap16_t"] likewise.  If code
written for a compiler that could support such types used them in preference
to "uint16_t" or "uint32_t" in cases where wrapping behavior was important,
such usage could then facilitate migration of the code to other platforms,
both because:

 (1) If such types became popular, 32-bit compilers could add support for
     uwrap16_t, and 64-bit compilers could add support for uwrap32_t (it
     would be necessary to have the compiler keep track of the sizes of
     things that get promoted to "int", to determine when an operations
     between such values and the "uwrapN_t" types should yield signed or
     unsigned results, but that shouldn't be overly complicated).

 (2) Even if compilers never gain such abilities, having the compiler squawk
     at places where it will be necessary to adjust code to yield correct
     behavior would be better than having a 64-bit compiler decide that an
     operation (e.g. multiplying two "uint32_t" values and storing the result
     in a "uint32_t" variable) which would have been fully defined on all
     platforms where "int" was either 32 bits or less, or 65 bits or more,
     should be used as an excuse to yield arbitrary behavior on a platform
     where "int" is 33 to 64 bits.

A good language should make it practical to write code that will run
identically on all platforms *where it compiles*, and define a level of
standards-compliance for programs which use features that compilers are
not required to support, but but are required to complain about if not
supported.  Unfortunately, I'm unaware of such a viewpoint having any
traction among those responsible for the language.

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

#70003

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Tuesday, September 8, 2015 at 3:17:41 PM UTC-4, Ben Bacarisse wrote:
>> Ken Brody <kenbrody@spamcop.net> writes:
>> > Can an enum be forced to a certain "bitness"?
>> > For example, can I force an enum to be "int16_t"?
>> 
>> No.
>
> This is a fundamental flaw in the language.

Where can I find the specification of how RDC handles enumerated types?

-- 
Ben.

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

#70008

On Tuesday, September 8, 2015 at 7:42:11 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Tuesday, September 8, 2015 at 3:17:41 PM UTC-4, Ben Bacarisse wrote:
> >> Ken Brody <kenbrody@spamcop.net> writes:
> >> > Can an enum be forced to a certain "bitness"?
> >> > For example, can I force an enum to be "int16_t"?
> >> 
> >> No.
> >
> > This is a fundamental flaw in the language.
> 
> Where can I find the specification of how RDC handles enumerated types?

The specification is here:

    https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/compiler/rdc/rdc_specs.txt

It has no definition on how it handles enumerated types.

I consider the concept of macro expansion to be a mechanical process
generating source code which is then compild.

I consider enums to be a list creating mechanism assigning a relationship
between names which and something they relate to (typically numbers, but
possibly other tokens).

RDC does not require forward declaration of most things (local variables
are the exception).

In RDC, this is valid:

    // RDC source code:
    s8 color = red;

    function main
    | returns int
    | params int argc, char* argv[]
    {
        fred();
    }

    function fred
    {
        printf("Hi, Ben! :-)\n");
    }

    enum { red = 0, grn = 1, blu = 2 };

-----
RDC is tightly coupled to the GUI IDE and it will show you where red
is defined when you are on that source code line, so it does not need
to be anywhere in particular.

Best regards,
Rick C. Hodgin

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

#70012

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Tuesday, September 8, 2015 at 7:42:11 PM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> 
>> > On Tuesday, September 8, 2015 at 3:17:41 PM UTC-4, Ben Bacarisse wrote:
>> >> Ken Brody <kenbrody@spamcop.net> writes:
>> >> > Can an enum be forced to a certain "bitness"?
>> >> > For example, can I force an enum to be "int16_t"?
>> >> 
>> >> No.
>> >
>> > This is a fundamental flaw in the language.
>> 
>> Where can I find the specification of how RDC handles enumerated types?
>
> The specification is here:
>
>     https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/compiler/rdc/rdc_specs.txt
>
> It has no definition on how it handles enumerated types.

That seems like a fundamental flaw in the language.

<snip>
-- 
Ben.

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

#70014

On Tuesday, September 8, 2015 at 8:32:01 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> > On Tuesday, September 8, 2015 at 7:42:11 PM UTC-4, Ben Bacarisse wrote:
> >> Where can I find the specification of how RDC handles enumerated types?
> >
> > The specification is here:
> >
> >     https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/compiler/rdc/rdc_specs.txt
> >
> > It has no definition on how it handles enumerated types.
> 
> That seems like a fundamental flaw in the language.

:-) Funny.

It's not a fundamental flaw in the language, because the language does
define how it handles enumerated types.  I just haven't written it down
in the documentation yet because there are some things I consider to be
a given, or very straight-forward.  Nonetheless, I have a very clear
form in my mind that will be adhered to (James 4:15).

And, FWIW, there are some things that will be conveyed by example
rather than writing out formal specs.  An example is often worth a
few thousand words.

Here's probably how I would define it:

     enum [name]
     {
         name1  [= thing1]  [,]
         [nameN [= thingN]]
     };
     // If thing1 or thingN is specified, and others following are
     // not, they will be given incrementally increasing values.
     // If no thing1 is specified, assignment begins at 0.

[name] is optional, name1 is not optional, thing1 is optional, and
this pattern repeats forward for N items.  Each comma is optional
if the items are on separate source code lines.  No trailing comma
is allowed however, because it's just wrong.

-----
In RDC, Enums will also not be types allowed in classes or structs
directly, but only identified to each member indirectly, as in:

     enum colors { red, grn, blu };

     struct SAbc
     {
         s32 backColor range colors [loose];
     };

This will indicate it has a specific type size, and its explicitly
stored input must of the values found in colors.  The optional keyword
loose would indicate that enums red, grn, blu can be used, as can
their enum values 0, 1, 2 directly.  Without loose, only red, grn, blu
would be allowed.

...if I ever complete RDC that is (James 4:15 -- "Lord willing").

Best regards,
Rick C. Hodgin

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

#70022

Rick C. Hodgin wrote:
> On Tuesday, September 8, 2015 at 3:17:41 PM UTC-4, Ben Bacarisse wrote:
>> Ken Brody <kenbrody@spamcop.net> writes:
>>> Can an enum be forced to a certain "bitness"?
>>> For example, can I force an enum to be "int16_t"?
>>
>> No.
>
> This is a fundamental flaw in the language.
>
> Best regards,
> Rick C. Hodgin
>


It's an r-value. It needs no type. The type-wavefunction
collapses only when it's used in an assignment.

-- 
Les Cargill

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

#70028

On 09/09/2015 04:53, Les Cargill wrote:
> Rick C. Hodgin wrote:
>> On Tuesday, September 8, 2015 at 3:17:41 PM UTC-4, Ben Bacarisse wrote:
>>> Ken Brody <kenbrody@spamcop.net> writes:
>>>> Can an enum be forced to a certain "bitness"?
>>>> For example, can I force an enum to be "int16_t"?
>>>
>>> No.
>>
>> This is a fundamental flaw in the language.


>
> It's an r-value. It needs no type. The type-wavefunction
> collapses only when it's used in an assignment.

Why shouldn't it have a type? The following displays "4":

enum {red,green} colour;

printf("%d\n",sizeof(colour));

So it has a size, at least.

-- 
Bartc

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

#70030

Bartc <bc@freeuk.com> writes:

> On 09/09/2015 04:53, Les Cargill wrote:
>> Rick C. Hodgin wrote:
>>> On Tuesday, September 8, 2015 at 3:17:41 PM UTC-4, Ben Bacarisse wrote:
>>>> Ken Brody <kenbrody@spamcop.net> writes:
>>>>> Can an enum be forced to a certain "bitness"?
>>>>> For example, can I force an enum to be "int16_t"?
>>>>
>>>> No.
>>>
>>> This is a fundamental flaw in the language.
>
>>
>> It's an r-value. It needs no type. The type-wavefunction
>> collapses only when it's used in an assignment.
>
> Why shouldn't it have a type?

Given the reference to wave functions, I don't think Les was be serious.

> The following displays "4":
>
> enum {red,green} colour;
>
> printf("%d\n",sizeof(colour));
>
> So it has a size, at least.

There maybe some confusion here.  enum constants are of type int, so it
is natural that an object declared with an enum type should be large
enough to hold an int.  So red and green are of type int, but colour is
of enum type (one that can not be named because you gave it no tag).

You can tell (nowadays) what type something is.  This:

  #include <stdio.h>

  int main(void)
  {
       enum E {red, green} colour;
       puts(_Generic(colour, int: "int", enum E: "enum"));
       puts(_Generic(green,  int: "int", enum E: "enum"));
  }

if compiled with a suitable compiler, will print enum then int.

-- 
Ben.

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

#70038

On 09/09/15 12:27, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
> 
>> On 09/09/2015 04:53, Les Cargill wrote:
>>> Rick C. Hodgin wrote:
>>>> On Tuesday, September 8, 2015 at 3:17:41 PM UTC-4, Ben Bacarisse wrote:
>>>>> Ken Brody <kenbrody@spamcop.net> writes:
>>>>>> Can an enum be forced to a certain "bitness"?
>>>>>> For example, can I force an enum to be "int16_t"?
>>>>>
>>>>> No.
>>>>
>>>> This is a fundamental flaw in the language.
>>
>>>
>>> It's an r-value. It needs no type. The type-wavefunction
>>> collapses only when it's used in an assignment.
>>
>> Why shouldn't it have a type?
> 
> Given the reference to wave functions, I don't think Les was be serious.
> 
>> The following displays "4":
>>
>> enum {red,green} colour;
>>
>> printf("%d\n",sizeof(colour));
>>
>> So it has a size, at least.
> 
> There maybe some confusion here.  enum constants are of type int, so it
> is natural that an object declared with an enum type should be large
> enough to hold an int.  So red and green are of type int, but colour is
> of enum type (one that can not be named because you gave it no tag).
> 
> You can tell (nowadays) what type something is.  This:
> 
>   #include <stdio.h>
> 
>   int main(void)
>   {
>        enum E {red, green} colour;
>        puts(_Generic(colour, int: "int", enum E: "enum"));
>        puts(_Generic(green,  int: "int", enum E: "enum"));
>   }
> 
> if compiled with a suitable compiler, will print enum then int.
> 

I always wondered if there were good, real-world uses of _Generic...

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

#70092

Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
>
>> On 09/09/2015 04:53, Les Cargill wrote:
>>> Rick C. Hodgin wrote:
>>>> On Tuesday, September 8, 2015 at 3:17:41 PM UTC-4, Ben Bacarisse wrote:
>>>>> Ken Brody <kenbrody@spamcop.net> writes:
>>>>>> Can an enum be forced to a certain "bitness"?
>>>>>> For example, can I force an enum to be "int16_t"?
>>>>>
>>>>> No.
>>>>
>>>> This is a fundamental flaw in the language.
>>
>>>
>>> It's an r-value. It needs no type. The type-wavefunction
>>> collapses only when it's used in an assignment.
>>
>> Why shouldn't it have a type?
>
> Given the reference to wave functions, I don't think Les was be serious.
>

I was, sorta. enums are really an abstraction. As an implementation 
detail, they probably are ints so far as the toolchain goes but
I remember Pascal where they were an abstraction - as I recall,
you could not assign them to an integer type.

This, of course, varied by implementation.

>> The following displays "4":
>>
>> enum {red,green} colour;
>>
>> printf("%d\n",sizeof(colour));
>>
>> So it has a size, at least.
>
> There maybe some confusion here.  enum constants are of type int, so it
> is natural that an object declared with an enum type should be large
> enough to hold an int.  So red and green are of type int, but colour is
> of enum type (one that can not be named because you gave it no tag).
>
> You can tell (nowadays) what type something is.  This:
>
>    #include <stdio.h>
>
>    int main(void)
>    {
>         enum E {red, green} colour;
>         puts(_Generic(colour, int: "int", enum E: "enum"));
>         puts(_Generic(green,  int: "int", enum E: "enum"));
>    }
>
> if compiled with a suitable compiler, will print enum then int.
>

-- 
Les Cargill

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

#70101

Les Cargill <lcargill99@comcast.com> writes:
> Ben Bacarisse wrote:
>> Bartc <bc@freeuk.com> writes:
>>> On 09/09/2015 04:53, Les Cargill wrote:
[...]
>>>> It's an r-value. It needs no type. The type-wavefunction
>>>> collapses only when it's used in an assignment.
>>>
>>> Why shouldn't it have a type?
>>
>> Given the reference to wave functions, I don't think Les was be serious.
>>
>
> I was, sorta. enums are really an abstraction. As an implementation 
> detail, they probably are ints so far as the toolchain goes but
> I remember Pascal where they were an abstraction - as I recall,
> you could not assign them to an integer type.

Enumerated types are no more an abstraction than any other type in C.

They're explained in N1570 6.2.5p16 and 6.7.2.2.

[...]

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

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

#70091

Bartc wrote:
> On 09/09/2015 04:53, Les Cargill wrote:
>> Rick C. Hodgin wrote:
>>> On Tuesday, September 8, 2015 at 3:17:41 PM UTC-4, Ben Bacarisse wrote:
>>>> Ken Brody <kenbrody@spamcop.net> writes:
>>>>> Can an enum be forced to a certain "bitness"?
>>>>> For example, can I force an enum to be "int16_t"?
>>>>
>>>> No.
>>>
>>> This is a fundamental flaw in the language.
>
>
>>
>> It's an r-value. It needs no type. The type-wavefunction
>> collapses only when it's used in an assignment.
>
> Why shouldn't it have a type? The following displays "4":
>
> enum {red,green} colour;
>
> printf("%d\n",sizeof(colour));
>
> So it has a size, at least.
>

It doesn't have a type *per se*. This is just 'C', where
"when in doubt, it's an int."

I bet "printf("%9.4f\n",(float)green);" prints "   1.0000", too.

-- 
Les Cargill

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

#70100

Les Cargill <lcargill99@comcast.com> writes:
> Bartc wrote:
[...]
>> Why shouldn't it have a type? The following displays "4":
>>
>> enum {red,green} colour;
>>
>> printf("%d\n",sizeof(colour));
>>
>> So it has a size, at least.
>
> It doesn't have a type *per se*.

Of course it has a type.  That type is the anonymous enumerated type
created by `enum {red,green}`.  The type is compatible with an
implementation-defined integer type (which may or may not be int).

Why do you think it doesn't have a type?

>                                  This is just 'C', where
> "when in doubt, it's an int."

That may be true, but only because there are no cases where there's any
doubt (unless you can think of one).

[...]

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

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

#70113

Keith Thompson wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> Bartc wrote:
> [...]
>>> Why shouldn't it have a type? The following displays "4":
>>>
>>> enum {red,green} colour;
>>>
>>> printf("%d\n",sizeof(colour));
>>>
>>> So it has a size, at least.
>>
>> It doesn't have a type *per se*.
>
> Of course it has a type.  That type is the anonymous enumerated type
> created by `enum {red,green}`.

Of course. I meant "... have a type beyond the enum." I thought
that was sufficiently tautological to be unnecessary. :)

'C' doesn't keep you from taking the address of a variable
declared as an enum type.  Feh.


> The type is compatible with an
> implementation-defined integer type (which may or may not be int).
>
> Why do you think it doesn't have a type?
>

It just doesn't need one.

int v = green;

is exactly the same as

int v = 1;


>>                                   This is just 'C', where
>> "when in doubt, it's an int."
>
> That may be true, but only because there are no cases where there's any
> doubt (unless you can think of one).
>
> [...]
>

-- 
Les Cargill

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

#70117

Les Cargill <lcargill99@comcast.com> writes:
> Keith Thompson wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
>>> Bartc wrote:
>> [...]
>>>> Why shouldn't it have a type? The following displays "4":
>>>>
>>>> enum {red,green} colour;
>>>>
>>>> printf("%d\n",sizeof(colour));
>>>>
>>>> So it has a size, at least.
>>>
>>> It doesn't have a type *per se*.
>>
>> Of course it has a type.  That type is the anonymous enumerated type
>> created by `enum {red,green}`.
>
> Of course. I meant "... have a type beyond the enum." I thought
> that was sufficiently tautological to be unnecessary. :)

It doesn't "have a type beyond the enum".  Well, it's an enum type; what
other type does it need?

> 'C' doesn't keep you from taking the address of a variable
> declared as an enum type.  Feh.

No, it doesn't.  Why should it?

>> The type is compatible with an
>> implementation-defined integer type (which may or may not be int).
>>
>> Why do you think it doesn't have a type?
>>
>
> It just doesn't need one.
>
> int v = green;
>
> is exactly the same as
>
> int v = 1;

green is of type int, not of the enum type.  But the enum type is a
distinct type, and if you give it a name you can define objects of that
type, pointers to that type, and so forth.

If your point is that C's treatment of enum types is odd, I agree.
If you have a different point, it eludes me.

[...]

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

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

#70126

Keith Thompson wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> Keith Thompson wrote:
>>> Les Cargill <lcargill99@comcast.com> writes:
>>>> Bartc wrote:
>>> [...]
>>>>> Why shouldn't it have a type? The following displays "4":
>>>>>
>>>>> enum {red,green} colour;
>>>>>
>>>>> printf("%d\n",sizeof(colour));
>>>>>
>>>>> So it has a size, at least.
>>>>
>>>> It doesn't have a type *per se*.
>>>
>>> Of course it has a type.  That type is the anonymous enumerated type
>>> created by `enum {red,green}`.
>>
>> Of course. I meant "... have a type beyond the enum." I thought
>> that was sufficiently tautological to be unnecessary. :)
>
> It doesn't "have a type beyond the enum".  Well, it's an enum type; what
> other type does it need?
>

I've confused you  :) I think it needs no type, that it is
*inherently* a simple substitution and only exists in ... source code
space.

>> 'C' doesn't keep you from taking the address of a variable
>> declared as an enum type.  Feh.
>
> No, it doesn't.  Why should it?
>

Because why would you take the address of an enum type? I understand
that it's a facade over the int type. That's not my argument.

I just think that's unnecessary, philosophically.

>>> The type is compatible with an
>>> implementation-defined integer type (which may or may not be int).
>>>
>>> Why do you think it doesn't have a type?
>>>
>>
>> It just doesn't need one.
>>
>> int v = green;
>>
>> is exactly the same as
>>
>> int v = 1;
>
> green is of type int, not of the enum type.


Right.

> But the enum type is a
> distinct type, and if you give it a name you can define objects of that
> type, pointers to that type, and so forth.
>
> If your point is that C's treatment of enum types is odd, I agree.


That's basically it. And I'm sure it comes in handy, being
equivalent to an int.

> If you have a different point, it eludes me.
>

I think that enums or typedef enums could be abstract values
that don't exist past compilation.

> [...]
>

-- 
Les Cargill

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

#70186

Les Cargill <lcargill99@comcast.com> writes:
> Keith Thompson wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
>>> Keith Thompson wrote:
>>>> Les Cargill <lcargill99@comcast.com> writes:
>>>>> Bartc wrote:
>>>> [...]
>>>>>> Why shouldn't it have a type? The following displays "4":
>>>>>>
>>>>>> enum {red,green} colour;
>>>>>>
>>>>>> printf("%d\n",sizeof(colour));
>>>>>>
>>>>>> So it has a size, at least.
>>>>>
>>>>> It doesn't have a type *per se*.
>>>>
>>>> Of course it has a type.  That type is the anonymous enumerated type
>>>> created by `enum {red,green}`.
>>>
>>> Of course. I meant "... have a type beyond the enum." I thought
>>> that was sufficiently tautological to be unnecessary. :)
>>
>> It doesn't "have a type beyond the enum".  Well, it's an enum type; what
>> other type does it need?
>
> I've confused you  :) I think it needs no type, that it is
> *inherently* a simple substitution and only exists in ... source code
> space.

Are you trying to describe some language other than C?

Every C expression has a well-defined type.  The type of the constant
`green` is int, as is the type of the constant `1`.  I have no idea what
you mean when you say that something "needs" no type; the fact is, they
have a type, and the semantics of any C construct using them depends on
that type.

>>> 'C' doesn't keep you from taking the address of a variable
>>> declared as an enum type.  Feh.
>>
>> No, it doesn't.  Why should it?
>
> Because why would you take the address of an enum type? I understand
> that it's a facade over the int type. That's not my argument.

Of course you can't take the address of a type.  But it makes perfectly
good sense to take the address of an object of an enum type.  Consider:

    enum color { red, green }; /* I've added a tag */
    enum color foo;

    void set_color(enum color *c) { *c = green; }

    set_color(&foo);

This is a contrived example that does something that could be
accomplished more easily by writing `foo = green;`, but you can
imagine a more elaborate scenario.

> I just think that's unnecessary, philosophically.

I just think you're mistaken.

[...]

>> But the enum type is a
>> distinct type, and if you give it a name you can define objects of that
>> type, pointers to that type, and so forth.
>>
>> If your point is that C's treatment of enum types is odd, I agree.
>
> That's basically it. And I'm sure it comes in handy, being
> equivalent to an int.

An enum type is not equivalent to an int; it's compatible with
some implementation-defined integer type.  (gcc uses unsigned int,
or int if there are negative values; the behavior can be changed
with a command-line option `-fshort-enums`.)

>> If you have a different point, it eludes me.
>
> I think that enums or typedef enums could be abstract values
> that don't exist past compilation.

Ok, perhaps they could be.  But they aren't.  Or rather, they're no
more abstract than any other type.  (If int and long are the same
size, for example, the distinction between int and long doesn't
exist past compilation either.)

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

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

#70120

On 09/09/2015 11:27 PM, Les Cargill wrote:
> Keith Thompson wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
...
>>> It doesn't have a type *per se*.
>>
>> Of course it has a type.  That type is the anonymous enumerated type
>> created by `enum {red,green}`.
> 
> Of course. I meant "... have a type beyond the enum." I thought
> that was sufficiently tautological to be unnecessary. :)

I don't see it as tautological - primarily, perhaps, because I'm not
sure what it even means. Can you describe what feature of C would have
to be different, in order for you to say "It does have a type beyond the
enum." That might give me a better idea of what you mean by that phrase.

> 'C' doesn't keep you from taking the address of a variable
> declared as an enum type.  Feh.
> 
> 
>> The type is compatible with an
>> implementation-defined integer type (which may or may not be int).
>>
>> Why do you think it doesn't have a type?
>>
> 
> It just doesn't need one.
> 
> int v = green;
> 
> is exactly the same as
> 
> int v = 1;

green and 1 are both defined by the standard as having the type 'int'.
If, as you claim, they don't need types, that implies that the meaning
of those expressions would be the same even if green and 1 didn't have a
type. The rules for initializers cross-reference the rules for simple
assignment. 6.5.16.1p1 says "one of the following shall hold". Can you
please identify which of the items in that section could possibly apply
to a typeless right operand? As far as I could see, each item imposed
type-based requirements of some kind on the right operand.
-- 
James Kuyper

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

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

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

csiph-web