Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: clarification about enums in C Date: Fri, 28 Feb 2020 01:27:47 -0800 Organization: None to speak of Lines: 26 Message-ID: <87a753t624.fsf@nosuchdomain.example.com> References: <5c585469-72c8-42f8-9e74-848f160db602@googlegroups.com> <87imjst80s.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="45d8797b4cf74f417b3a254c44fb9e68"; logging-data="9411"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+BzohHNEpBvfZq5Ur31Ddx" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:e0MmfT0xKvApDu6Rk2vslJ3sE20= sha1:4XKWCNtY1jicEkl/XZLyC5OgD1Q= Xref: csiph.com comp.lang.c:150326 Keith Thompson writes: > David Brown writes: > [...] >>> enum enum_t { >>> uns = (unsigned)-1, >>> neg = -1, >>> }; >>> Both in gcc and in clang uns has type 'unsigned int' rather than 'int'. >>> And indeed it differs from type of 'enum_t' which in ths case is 'int'. >> >> This is an extension that these tools support - as do many compilers. >> If you want to ensure that you stick to standards-only code, use >> "-Wpedantic" (along with your choice of -std=c11, -std=c99 or -std=c90), >> and pay attention to the warnings. The C standard does not say how >> "uns" should be treated, gcc's extensions do the "obvious" thing. > > Ah, but gcc doesn't print a diagnostic with "-std=c11 -Wpedantic", even > though the code violates a constraint. Um, yes it does. I don't know what I did wrong that led me to think otherwise. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */