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 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#70259

David Brown wrote:
> On 11/09/15 11:40, Richard Heathfield wrote:
>> On 11/09/2015 10:38, David Brown wrote:
>>> On 11/09/15 11:24, Ian Collins wrote:
>>>
>>>>
>>>>   Yes, but as David pointed out this is unnecessary given the sensible
>>>>   const rules in C++!
>>>>
>>>
>>> Let's call the const rules in C++ "less bad", rather than "sensible".
>>>
>>> I gather that the original keyword was "readonly", which I think would
>>> have been better.  But when we have "const" to mean something is
>>> constant and doesn't change, then "mutable" to mean that it might change
>>> after all, then "constexpr" to mean that this time we /really/ mean it
>>> won't change - it's hard to summarise the situation as "sensible" !
>>
>> That's the trouble with programming languages - constants aren't,
>> variables don't, and functions won't.
>>
>
> But objects do :-)
>

... inexplicable things :)

-- 
Les Cargill

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

#70283

On Friday, September 11, 2015 at 4:38:47 AM UTC-5, David Brown wrote:
>  In C, the rules say that changing the value of the const would be
> undefined behaviour - yet the compiler can't use that fact to let you
> use the value as a compile-time constant for array sizes.

Given `extern const int foo;`, the C Standard says that no C code is allowed to
modify `foo`, but says nothing about whether `foo` might be modified in some
way that the compiler doesn't know about.  In some embedded systems, it would
not be uncommon to have code to say something like:

    const char serialNumber="ACME123456";

and then have a utility which, after determining that the string "ACME123456"
only appeared once in the binary image, replaced it with the serial number of
each product as it was manufactured.  For the Standard to say that compilers
had to allow `const` values to be usable everyplace constant expressions are
usable would break existing applications which use such techniques; it might
not be too bad if `const volatile` variables were required to acknowledge the
possibility of such "unexpected" alteration, but I don't know that much code
using such techniques uses `volatile` if the content can never change during
program execution.

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

#70340

On 12/09/15 00:03, supercat@casperkitty.com wrote:
> On Friday, September 11, 2015 at 4:38:47 AM UTC-5, David Brown wrote:
>>   In C, the rules say that changing the value of the const would be
>> undefined behaviour - yet the compiler can't use that fact to let you
>> use the value as a compile-time constant for array sizes.
>
> Given `extern const int foo;`, the C Standard says that no C code is allowed to
> modify `foo`, but says nothing about whether `foo` might be modified in some
> way that the compiler doesn't know about.  In some embedded systems, it would
> not be uncommon to have code to say something like:
>
>      const char serialNumber="ACME123456";
>
> and then have a utility which, after determining that the string "ACME123456"
> only appeared once in the binary image, replaced it with the serial number of
> each product as it was manufactured.  For the Standard to say that compilers
> had to allow `const` values to be usable everyplace constant expressions are
> usable would break existing applications which use such techniques; it might
> not be too bad if `const volatile` variables were required to acknowledge the
> possibility of such "unexpected" alteration, but I don't know that much code
> using such techniques uses `volatile` if the content can never change during
> program execution.
>

If you write

	const char serialNumber[] = "ACME123456";

then there is no legal way - including modifying the binary image - in 
which you can cause that serialNUmber constant to be any other value, as 
seen in the translation unit that contains the definition.

If you write "extern const char serialNumber", then that translation 
unit does not know the value if it has been compiled separately - 
noting, however, that if you use whole-program or link-time optimisation 
then the compiler knows values across units.

In C++, a "const" without "extern" is treated as "static const" - then 
the compiler can be entirely sure that it knows everything about the 
constant.  In C, you have to add "static" explicitly (I would not mind 
having to use "static int bufferSize = 100;" if it let me write "char 
buffer[bufferSize];", even though I think the static should be unnecessary).

In C and C++, if something can change without the compiler's knowledge, 
you use "volatile".  That includes something like a serial number that 
is modified after code generation.  This is what "volatile const" is 
for.  (It can also be used for read-only hardware registers and the 
like.)  I have done precisely this sort of thing - and used "volatile 
const" for such serial numbers.

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

#70213

On 11/09/15 01:32, Ian Collins wrote:
> David Brown wrote:
>> On 09/09/15 13:36, Bartc wrote:
>>>
>>> You mean, having arrays that can only be indexed by a particular enum
>>> type? That would be very Ada-ish.
>>>
>>
>> Yes, like having:
>>
>> typedef enum { black, red, green, blue, white } colours;
>> typedef struct { uint8_t R; uint8_t G; uint8_t B } rgb;
>> static const rgb rgbs[colours] = {
>>     { 0, 0, 0 }, { 255, 0, 0 }, ...
>> }
>>
>> void foo(colours c) {
>>     set_rgb(rgbs[c]);
>> }
>>
>> I would also like to be able to write "last(colours)" rather than having
>> to put an artificial entry "last_colour" into the colours enum (or
>> making it as a separate declaration).
> 
> The reflections proposals for C++ go a long way to implementing these,
> see N4428.

There are some interesting ideas there.  It looks like they are trying
to make a sort of extended RTTI interface, which is not something I
would need in my own code, but it will also cover the compile-time
information such as the number of elements in an enum type.

> 
>>> But in C (and in C++ AFAIK), enums are not necessarily sequential. In
>>> fact, a set of enums can have arbitrary values, or can all have the same
>>> value! That would give with problems with features such as successor and
>>> predecessor functions, or even just turn an enum instance value into the
>>> same of the value.
>>>
>>> Although I suspect that more sophisticated uses of enums will come with
>>> restrictions.
>>>
>>
>> Exactly.  It would be perfectly reasonable to limit such advanced enum
>> use to sequential enums.  Indeed, for many uses of non-sequential enums
>> (such as names for bitmasks), C++'s "enum class" would not be suitable
>> as you don't have direct access to the underlying number.  I don't think
>> it would have been a big loss if "enum class" had been defined as always
>> being sequential, starting from 0 - non-sequential enum uses could have
>> used old-style "enum".
> 
> There is a middle ground that I have already used in embedded C++, typed
> enums (not full blown enum class) such as
> 
> enum State : uint16_t { on = 0x001, off = 0x002 };
> 
> which allows conversion to the base type
> 
>   uint16_t u = State::on;

That's a sort of half-way between "enum" and "enum class" - you can
specify the size of the underlying type, and the identifiers are
enumerated, but you don't have the strong type protection to stop
implicit conversions between the enum and integer types?

I like the strong typing of "enum class" - it stops accidents.  But on
the other hand, I would like to be able to refer to the underlying
number on occasion, something that "enum class" makes difficult.

I guess the answer is to write a set of template classes and functions
that let me access the enum class underlying type in a reasonably clear
way - the kind of templates that C fans don't like because they look
hideous and complicated, yet don't actually /do/ anything or produce any
code, and which C++ fans like because they let you use the language in
new ways.

> 
> I don't see why this, being a new syntax, couldn't be adopted in C or
> included as an extension for embedded compilers.
> 

Identifier scope like that does not fill well with existing C.  But
specifying the size of the underlying type of the enum is not
unreasonable, and is certainly something that could make sense for
compiler extensions.  gcc (and I guess also clang) has a "packed"
attribute for enums that make them take the smallest type that covers
all elements.

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

#70131

On 10/09/15 02:46, Stefan Ram wrote:
> Bartc <bc@freeuk.com> writes:
>> You mean, having arrays that can only be indexed by a particular enum 
>> type? That would be very Ada-ish.
> 
>   I believe that Pascal existed before Ada.
>   In Pascal, one can write:
> 
> PROGRAM EXAMPLE( INPUT, OUTPUT );
> 
> TYPE ONETWOTHREETYPE = 1..3;
> 
> VAR A: ARRAY[ ONETWOTHREETYPE ] OF ONETWOTHREETYPE;
> 
> BEGIN
>   A[ 3 ] := 4; WRITELN( A[ 3 ])
> END.
> 
>   The »4« is not allowed to be assigned to a variable of the type
>   »ONETWOTHREETYPE«. The Pascal implementation I use does not detect
>   this error at compile time, but at run-time, though. A run-time
>   detection we can do in C++, or even in C if we use an appropriate
>   function
> 
> a_assign( 3, 4 ); /* for: a[ 3 ]= 4 */
> 
>   .

Yes, Pascal preceded Ada and was a strong influence on the language, and
yes, Pascal supports using enumerations and sub-ranges as indexes for
arrays.

But Bart was still correct to suggest that my idea was Ada-ish, and it
was Ada's support that inspired by post (though it could have been
inspired by Pascal or Modula-2 - especially since I have written a lot
of Pascal code over the years, and almost no Ada code).

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

#70594

On Wednesday, September 9, 2015 at 4:36:23 AM UTC-7, Bart wrote:
> On 09/09/2015 10:07, David Brown wrote:
> > On 09/09/15 00:35, Ian Collins wrote:
> 
> >> If you want type safe and fixed size enums, use C++. C
> >> enums are something of a wasted opportunity.
> 
> > So they are not a /completely/ wasted opportunity, even though the
> > compiler itself makes little use of them.
> >
> > As you say, C++ gives you more type safety and control with "enum class"
> > types.  But that too is full of wasted opportunity - they should have
> > supported Ada-style attributes for first, last, successor, predecessor,
> > iterators, conversion to and from integer (but not implicit conversion),
> > and they should be usable as the index for arrays.
> 
> You mean, having arrays that can only be indexed by a particular enum 
> type? That would be very Ada-ish.
> 
> But in C (and in C++ AFAIK), enums are not necessarily sequential. In 
> fact, a set of enums can have arbitrary values, or can all have the same 
> value! That would give with problems with features such as successor and 
> predecessor functions, or even just turn an enum instance value into the 
> same of the value.
> 
> Although I suspect that more sophisticated uses of enums will come with 
> restrictions.

I don't know the history of "enum" but the simplest meaning would be
"here is a set of different things". All you could with these things is
svae them and compare them. Sizeof would be implementation-defined.   

The next step would be to order them (linearly) and introduce 
predecessors and successors.  Immediate problem - circular? Like
the obvious example - days of the week.

I imagine the inventors of enum got this far and punted.

I think they should have stuck with it and declared the members of 
an enum circular. All you have to do to make it linear it add a null
to the circle between the ends.

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

#69988

On Tuesday September 8 2015 18:10, in comp.lang.c, "Bartc" <bc@freeuk.com>
wrote:

> On 08/09/2015 22:57, 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.
> 
> I don't agree.

I agree that not being able to force an enum into a "certain bitness" is not a
fundamental flaw in the C language.

> Take:
> 
>   enum (red,green,blue,yellow);
> 
> That's just a way of writing:

But, here I disagree.

>    #define red 0
>    #define green 1
>    etc

Macros are processed in a compilation phase prior to the evaluation of
enumerations. enum {red,green,blue,yellow}; /is not/ just another way of
writing
  #define red 0
etc.

You can't use the preprocessor stringize operator in enumerations.
An enumeration's value is not evident at the preprocessor stage. An
enumeration doesn't even share the same /namespace/ as a macro definition.

> What type is 0 or 1? Isn't it 'int' just like the enum?

No. At the /macro/ level, the argument of a define is just another token. It
has no C type until the macro is realized. 

Or, to think of it another way, if
  #define red 0
implies a 'type' of int on the value '0', then what sort of 'type' does
  #define FOREVER for(;;)
imply?

> So an enum is just a bunch of named values; it's not really a 'storage'
> type where you need to specify a narrow int or char type or even a 2-bit
> field.

Again, I believe that you are wrong. According to the C standard,
  "An enumeration comprises a set of named integer constant values."
where
  "An integer constant begins with a digit, but has no period or exponent
   part. It may have a prefix that specifies its base and a suffix that specifies
   its type."
and
  "The type of an integer constant is the first of [a list of standard integer
   constant promotions] in which its value can be represented.

So, enums are indeed integer values (/named/ integer values, at that) that can
(by use of an appropriate suffix) have the type of 
  (<<unsigned>>) (<<long>> (<<long>>) ) int

As for explicitly forcing an enumeration to a particular type alias (e.g.
int16_t), that operation seems to be outside the scope of the enum keyword,
and easily accomodated in code elsewhere.

[snip]

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#69997

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> On Tuesday September 8 2015 18:10, in comp.lang.c, "Bartc" <bc@freeuk.com>
> wrote:
[...]
>> What type is 0 or 1? Isn't it 'int' just like the enum?
>
> No. At the /macro/ level, the argument of a define is just another token. It
> has no C type until the macro is realized. 

The constants 0 and 1 are of type int.

> Or, to think of it another way, if
>   #define red 0
> implies a 'type' of int on the value '0', then what sort of 'type' does
>   #define FOREVER for(;;)
> imply?

0 is an expression, so it has a type, namely int.  for(;;) is not an
expression, and it doesn't have a type.

>> So an enum is just a bunch of named values; it's not really a 'storage'
>> type where you need to specify a narrow int or char type or even a 2-bit
>> field.
>
> Again, I believe that you are wrong. According to the C standard,
>   "An enumeration comprises a set of named integer constant values."
> where
>   "An integer constant begins with a digit, but has no period or exponent
>    part. It may have a prefix that specifies its base and a suffix that specifies
>    its type."
> and
>   "The type of an integer constant is the first of [a list of standard integer
>    constant promotions] in which its value can be represented.

An "integer constant" is a specific kind of token.  The "integer
constant values" of an enumeration are not syntactically "integer
constant"s.

> So, enums are indeed integer values (/named/ integer values, at that) that can
> (by use of an appropriate suffix) have the type of 
>   (<<unsigned>>) (<<long>> (<<long>>) ) int

No, enumeration constants are not integer constants (the standard's
wording is a bit sloppy in this area).  You can't apply a "0x"
prefix to an enumeration constant to make it hexadecimal, or a "UL"
suffix to make it unsigned long.

> As for explicitly forcing an enumeration to a particular type alias (e.g.
> int16_t), that operation seems to be outside the scope of the enum keyword,
> and easily accomodated in code elsewhere.
>
> [snip]

-- 
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]

#70005

On Tuesday September 8 2015 19:14, in comp.lang.c, "Keith Thompson"
<kst-u@mib.org> wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>> On Tuesday September 8 2015 18:10, in comp.lang.c, "Bartc" <bc@freeuk.com>
>> wrote:

[pertenant elided material restored]

>>    #define red 0
>>    #define green 1
>>    etc

>>> What type is 0 or 1? Isn't it 'int' just like the enum?
>>
>> No. At the /macro/ level, the argument of a define is just another token.
>> It has no C type until the macro is realized.
> 
> The constants 0 and 1 are of type int.

The preprocessor expansions of <<red> and <<green>> results in the
corresponding tokens of '0' and '1'. These tokens /have no type/ at this
point. They only have a type (and a value) when the preprocessor expansion
occurs in code where an integer type is relevant.

Consider
  #define Str(x) #x
  #define Xstr(x) Str(x)
  #define red 0

  char *String = Xstr(red);

Are you definitely certain that the value assigned to String is an integer?
You seem to say it is.

> 
>> Or, to think of it another way, if
>>   #define red 0
>> implies a 'type' of int on the value '0', then what sort of 'type' does
>>   #define FOREVER for(;;)
>> imply?
> 
> 0 is an expression, so it has a type, namely int.  for(;;) is not an
> expression, and it doesn't have a type.
> 
>>> So an enum is just a bunch of named values; it's not really a 'storage'
>>> type where you need to specify a narrow int or char type or even a 2-bit
>>> field.
>>
>> Again, I believe that you are wrong. According to the C standard,
>>   "An enumeration comprises a set of named integer constant values."
>> where
>>   "An integer constant begins with a digit, but has no period or exponent
>>    part. It may have a prefix that specifies its base and a suffix that
>>    specifies its type."
>> and
>>   "The type of an integer constant is the first of [a list of standard
>>   integer
>>    constant promotions] in which its value can be represented.
> 
> An "integer constant" is a specific kind of token.  The "integer
> constant values" of an enumeration are not syntactically "integer
> constant"s.
> 
>> So, enums are indeed integer values (/named/ integer values, at that) that
>> can (by use of an appropriate suffix) have the type of
>>   (<<unsigned>>) (<<long>> (<<long>>) ) int
> 
> No, enumeration constants are not integer constants (the standard's
> wording is a bit sloppy in this area).  You can't apply a "0x"
> prefix to an enumeration constant to make it hexadecimal, or a "UL"
> suffix to make it unsigned long.

OK, I can accept that.

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#70011

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> On Tuesday September 8 2015 19:14, in comp.lang.c, "Keith Thompson"
> <kst-u@mib.org> wrote:
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>> On Tuesday September 8 2015 18:10, in comp.lang.c, "Bartc" <bc@freeuk.com>
>>> wrote:
> [pertenant elided material restored]
>
>>>    #define red 0
>>>    #define green 1
>>>    etc
>
>>>> What type is 0 or 1? Isn't it 'int' just like the enum?
>>>
>>> No. At the /macro/ level, the argument of a define is just another token.
>>> It has no C type until the macro is realized.
>> 
>> The constants 0 and 1 are of type int.
>
> The preprocessor expansions of <<red> and <<green>> results in the
> corresponding tokens of '0' and '1'. These tokens /have no type/ at this
> point. They only have a type (and a value) when the preprocessor expansion
> occurs in code where an integer type is relevant.
>
> Consider
>   #define Str(x) #x
>   #define Xstr(x) Str(x)
>   #define red 0
>
>   char *String = Xstr(red);
>
> Are you definitely certain that the value assigned to String is an integer?
> You seem to say it is.

No, `Xstr(red)` expands to the string literal `"0"`, and the value used
to initialize String is of type char*.

Sure, a macro that expands to 0 is different from an enumeration
constant with the value 0.

[...]

-- 
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]

#69991

Bartc <bc@freeuk.com> writes:
> On 08/09/2015 22:57, 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.
>
> I don't agree.
>
> Take:
>
>   enum (red,green,blue,yellow);
>
> That's just a way of writing:
>
>    #define red 0
>    #define green 1
>    etc
>
> What type is 0 or 1? Isn't it 'int' just like the enum?

Yes.  To expand on that, the constants 0 and 1 are of type int because
the standard says so.  Enumeration constants are of type int because the
standard says so in a different rule.

> So an enum is just a bunch of named values; it's not really a 'storage' 
> type where you need to specify a narrow int or char type or even a 2-bit 
> field. That can be specified separately if it's important.

But an enumeration *type* is a distinct type.  For example, given:

    enum color { red, green, blue, yellow };
    enum color obj = blue;

the constants `red` et al are constant expressions of type int, but
`obj` is of type `enum color`.  The type `enum color` is compatible with
some implementation-defined integer type (gcc happens to use unsigned
int); that type must be able to hold the values of all the constants.
Which means, for example, that the initialization of `obj` may involve
an implicit conversion.

[...]

-- 
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]

#69995

On Tuesday, September 8, 2015 at 6:48:43 PM UTC-4, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:
> > Take:
> >
> >   enum (red,green,blue,yellow);
> >
> > That's just a way of writing:
> >
> >    #define red 0
> >    #define green 1
> >    etc
> >
> > What type is 0 or 1? Isn't it 'int' just like the enum?
> 
> Yes.  To expand on that, the constants 0 and 1 are of type int because
> the standard says so.  Enumeration constants are of type int because the
> standard says so in a different rule.

If this is true, that "#define red 0" actually creates an integer,
I would say this is another fundamental flaw with the language.

Best regards,
Rick C. Hodgin

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

#69998

Rick C. Hodgin wrote:
> On Tuesday, September 8, 2015 at 6:48:43 PM UTC-4, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>>> Take:
>>>
>>>    enum (red,green,blue,yellow);
>>>
>>> That's just a way of writing:
>>>
>>>     #define red 0
>>>     #define green 1
>>>     etc
>>>
>>> What type is 0 or 1? Isn't it 'int' just like the enum?
>>
>> Yes.  To expand on that, the constants 0 and 1 are of type int because
>> the standard says so.  Enumeration constants are of type int because the
>> standard says so in a different rule.
>
> If this is true, that "#define red 0" actually creates an integer,
> I would say this is another fundamental flaw with the language.

"#define red 0" does not create a integer.  It causes the text "red" to 
be replaced by "0".  The constant 0 is of type int.

-- 
Ian Collins

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

#69999

On Tuesday, September 8, 2015 at 7:16:44 PM UTC-4, Ian Collins wrote:
> Rick C. Hodgin wrote:
> > On Tuesday, September 8, 2015 at 6:48:43 PM UTC-4, Keith Thompson wrote:
> >> Bartc <bc@freeuk.com> writes:
> >>> Take:
> >>>
> >>>    enum (red,green,blue,yellow);
> >>>
> >>> That's just a way of writing:
> >>>
> >>>     #define red 0
> >>>     #define green 1
> >>>     etc
> >>>
> >>> What type is 0 or 1? Isn't it 'int' just like the enum?
> >>
> >> Yes.  To expand on that, the constants 0 and 1 are of type int because
> >> the standard says so.  Enumeration constants are of type int because the
> >> standard says so in a different rule.
> >
> > If this is true, that "#define red 0" actually creates an integer,
> > I would say this is another fundamental flaw with the language.
> 
> "#define red 0" does not create a integer.  It causes the text "red" to 
> be replaced by "0".  The constant 0 is of type int.

What is 0 in this case?

     char c = 0;

Is 0 an integer?  Or is it a char?

Best regards,
Rick C. Hodgin

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

#70000

On Tuesday, September 8, 2015 at 7:18:35 PM UTC-4, 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?..."

Best regards,
Rick C. Hodgin

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

#70004

Rick C. Hodgin wrote:
> On Tuesday, September 8, 2015 at 7:18:35 PM UTC-4, 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.

-- 
Ian Collins

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

#70007

Ian Collins <ian-news@hotmail.com> writes:

> Rick C. Hodgin wrote:
>> On Tuesday, September 8, 2015 at 7:18:35 PM UTC-4, 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.

Yes.  Specifically an octal constant -- one of those historical quirks
that some people find charming rather than absurd (like the right to
drive sheep over London Bridge, or living in a monarchy).

-- 
Ben.

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

#70037

On 09/09/15 01:52, Ben Bacarisse wrote:
> Ian Collins <ian-news@hotmail.com> writes:
> 
>> Rick C. Hodgin wrote:
>>> On Tuesday, September 8, 2015 at 7:18:35 PM UTC-4, 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.
> 
> Yes.  Specifically an octal constant -- one of those historical quirks
> that some people find charming rather than absurd (like the right to
> drive sheep over London Bridge, or living in a monarchy).
> 

I wouldn't call it a "charming" quirk.  It is mostly irritating, because
it leads to endless repeats of discussions like this:

A. We should deprecate octal integers, or at least have warnings on them
in all compilers.  After all, they are only used for unix file
permissions, and there are better ways to specify those, and they lead
to unexpected bugs in code that uses octals accidentally.

B. We can't deprecate octals - 0 is an octal and we can't live without
that.  Case closed.

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

#70059

David Brown <david.brown@hesbynett.no> writes:
[...]
> I wouldn't call it a "charming" quirk.  It is mostly irritating, because
> it leads to endless repeats of discussions like this:
>
> A. We should deprecate octal integers, or at least have warnings on them
> in all compilers.  After all, they are only used for unix file
> permissions, and there are better ways to specify those, and they lead
> to unexpected bugs in code that uses octals accidentally.
>
> B. We can't deprecate octals - 0 is an octal and we can't live without
> that.  Case closed.

The latter is a non-issue.  If a new standard deprecated octal
constants, it could easily tweak the grammar so that 0 is a decimal
constant.  Likewise 00, 000, et al.

(As for the first, I personally find 0700 much clearer than
S_IRUSR|S_IWUSR|S_IXUSR -- and it's much worse for things like 0755.)

-- 
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]

#70073

On 09/09/15 19:56, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> I wouldn't call it a "charming" quirk.  It is mostly irritating, because
>> it leads to endless repeats of discussions like this:
>>
>> A. We should deprecate octal integers, or at least have warnings on them
>> in all compilers.  After all, they are only used for unix file
>> permissions, and there are better ways to specify those, and they lead
>> to unexpected bugs in code that uses octals accidentally.
>>
>> B. We can't deprecate octals - 0 is an octal and we can't live without
>> that.  Case closed.
>
> The latter is a non-issue.  If a new standard deprecated octal
> constants, it could easily tweak the grammar so that 0 is a decimal
> constant.  Likewise 00, 000, et al.

That hasn't stopped exactly that non-issue being raised in previous 
threads on octals.  This is comp.lang.c - we can argue about anything!

>
> (As for the first, I personally find 0700 much clearer than
> S_IRUSR|S_IWUSR|S_IXUSR -- and it's much worse for things like 0755.)
>

Actually, I agree on that - at least for some code.  And I fully 
appreciate that the C committee never like to make changes that break 
existing code.  What I really hope for - and I don't think it is too 
unrealistic or unreasonable - is for compilers such as clang and gcc to 
provide an option to warn on octal usage (other than 0, of course).

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

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

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

csiph-web