Path: csiph.com!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 12:55:31 -0800 Organization: None to speak of Lines: 36 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=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: mx02.eternal-september.org; posting-host="4389ae8ca80d0229613347d13905988d"; logging-data="27355"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+2qVBDvJXaT1mLKN/K/yzM" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:FFQ92gxUhUDVmulVUqG6EL33ndk= sha1:xjUgCswtd/hnU1Xaifc8beNEOK4= Xref: csiph.com comp.lang.c:104036 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". The C++ definition is similar to C's. Quoting C++11: undefined behavior [defns.undefined] behavior for which this International Standard imposes no requirements [ Note: Undefined behavior may be expected when this International Standard omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed. — end note ] -- 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"