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: longer 'char literals' meaning in c Date: Thu, 30 Apr 2020 17:15:45 -0700 Organization: None to speak of Lines: 54 Message-ID: <87tv104ij2.fsf@nosuchdomain.example.com> References: <9bf151f2-e3f8-488b-bf10-9ba136d23a4f@googlegroups.com> <87sggk665l.fsf@nosuchdomain.example.com> <874kt061yl.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="3a8562cb4f6a88758e42aeb600e70f1e"; logging-data="30565"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19TuyL/EfXn21HHo+kcXy2o" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:FAyZYcnGtboTMCckt/+OpyVyJf4= sha1:pbVpmMp8VT6cCo1zzYZGq9NRYb8= Xref: csiph.com comp.lang.c:151897 Bart writes: > On 30/04/2020 23:30, Keith Thompson wrote: [...] >> There is no specified limit on the number of characters in a >> multi-character constant. > > I don't agree with that. If the extra characters can't be used and > shouldn't be there, then that's an error in my book. DMC agrees, and > further it explicitly states a maximum of 4 characters. What exactly do you disagree with? The C standard does not impose a limit on the number of characters in a multi-character constant. If you disagree with that, cite the wording in the standard that imposes such a limit. If you merely think that it *should* be an error, please make it clearer that you're stating your personal opinion rather than discussing what the standard says. DMC is the Digital Mars C compiler, yes? What exactly does it do with a character constant such as 'ABCDE'? If DMC does not attempt to be fully conforming by default, feel free to say what it does by default and what it does in conforming mode. If it rejects int n = 'ABCDE'; in a mode in which it claims to conform to the standard, that would be a bug. (A non-fatal warning would not violate the standard.) > But then gcc takes the same approach to obviously over-long integer > constants, and we're back into this same situation of needing to run > gcc with specially refined collections of options just to get it to do > the obvious thing. gcc is not fully conforming by default, and I'm not interested in getting into that discussion again. The C standard specifies the type and value of any integer constant, and says that that an integer constant whose value is outside the range of its type violates a constraint. I'm not aware of anything gcc does in this area that is non-conforming (or anything that I object to). What approach are you talking about? > My compiler, for all its other problems, will at least report > over-long char and integer constants as proper errors. So a program > with those faults cannot be compiled unless they are fixed. Are you referring to your C compiler? You are not required to make your compiler conform to the C standard, and you apparently have chosen not to do so. -- 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 */