Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: What if pre-processor was moved to parser? Date: Thu, 16 Feb 2017 14:02:31 -0800 Organization: None to speak of Lines: 37 Message-ID: References: <11c906d6-9be0-44df-82b4-157fdba3b91c@googlegroups.com> <436a6e24-df32-45d9-b24e-c1e135c32c24@googlegroups.com> <8b49e198-86a5-45b4-ade7-a27ecb4f5e07@googlegroups.com> <7cc856f7-997e-496d-8ebf-ba413cb89d75@googlegroups.com> <7dc5b761-29bb-4244-aa99-ed20cbfa5fcd@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="4389ae8ca80d0229613347d13905988d"; logging-data="27355"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Nj7trGKChDOWyamU38TY5" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:5pPYPOMJHuU+TVZ6xbOX8DapGEA= sha1:rWvuQznBUDp69hGHvkFVC7+66Kc= Xref: csiph.com comp.lang.c:104041 David Brown writes: > On 16/02/17 21:55, Keith Thompson wrote: >> David Brown writes: >> [...] >>> However, the reason "type punning" via unions was standardised in C99 is >>> that compilers already implemented it and people relied upon it. I >>> suspect you will find that any C++ compiler will support type punning >>> via unions, at least when constructors and destructors are not involved >>> - if you use type punning to gain access to an invalid object, that will >>> be UB. Certainly C++ does not /require/ that such type punning is UB. >> >> I'm not sure that last sentence makes sense. Either it's undefined >> behavior or it isn't. If the C++ standard doesn't define the behavior, >> then it's UB -- even if all implementations behave consistently. UB >> doesn't mean "it blows up". > > Supercat said that it "requires [that it] yields UB", which I > interpreted as him thinking the compiler /had/ to leave the behaviour > here without definition. It is not defined by the C Standards, but > there is no requirement for an implementation to leave it without a > definition. Supercat was either incorrect or stating something trivial, depending on how you interpret it. If a construct has undefined behavior, that means only that the standard does not define its behavior. It places no requirements of any kind on implementations. If a constructs behavior is not defined by the standard and an implementation chooses to define its behavior, then it still has "undefined behavior" as the standard defines and uses that phrase. I'm not sure what it means for something to "yield UB". -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"