Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!newsreader4.netcologne.de!news.netcologne.de!nx02.iad01.newshosting.com!newshosting.com!69.16.185.11.MISMATCH!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!news1.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 02 Dec 2011 07:35:55 -0600 Message-ID: <4ED8D43C.20B0@mindspring.com> Date: Fri, 02 Dec 2011 08:35:56 -0500 From: pete Reply-To: pfiland@mindspring.com Organization: PF X-Mailer: Mozilla 3.04Gold (WinNT; I) MIME-Version: 1.0 Newsgroups: comp.lang.c Subject: Re: Type interchange References: <4ED6AE65.8050901@verizon.net> <4ED6C5F0.1080608@verizon.net> <0.041cc3761d33f47105cd.20111201030905GMT.87d3c9ouni.fsf@bsb.me.uk> <4ED7A703.4658@mindspring.com> <4ED80320.7A05@mindspring.com> <4ED81BD0.4855@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 76 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 4.154.219.207 X-Trace: sv3-4N3Ov3w91A6xAc4qolSLBJxyvWH0L0rU4y6Aniq9MPGPvJqu5+Yd74s/556HtANJbua7THPpppT0PG2!oN2RqhQIpFXdU1W9RhM8E/7gittmBBcDTdpVEqClU3vBD0qaP8tBeL2HP+790MPZs7Q2IVx23SBO!A4ud9dZrAFc= X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 3909 Xref: x330-a1.tempe.blueboxinc.net comp.lang.c:14225 Keith Thompson wrote: > > pete writes: > > Keith Thompson wrote: > >> pete writes: > >> > Keith Thompson wrote: > >> >> pete writes: > >> >> > James Kuyper wrote: > >> >> >> Some people prefer to describe this by saying that if there's any > >> >> >> possible conforming implementation > >> >> >> where the behavior is undefined, then > >> >> >> the behavior is undefined, period, even on other implementations where > >> >> >> the condition that makes it undefined isn't true - but I find that > >> >> >> interpretation incoherent. > >> >> > > >> >> > That way, > >> >> > whether or not a program contains undefined behavior > >> >> > is a property of the C program, > >> >> > and not a property of the > >> >> > combination of the implementation and C program. > >> >> > >> >> int n = 32767; > >> >> n ++; > >> > > >> > The behavior of that code isn't limited by the standard, is it? > >> > >> If INT_MAX == 32767, then its behavior is undefined. Otherwise, its > >> behavior is well defined (it sets n to 32768). > >> > >> The point is that whether or not a program contains undefined > >> behavior already is "a property of the combination of the > >> implementation and C program". > > > > Whether or not a program is a "strictly conforming program" > > is not dependant on the implementation, > > Agreed. > > > and whether or not a program is a correct program > > is not dependant on the implementation. > > Depends on what you mean by "correct". > > > The code that you posted was intended to have a portability issue. > > Of course. > > > A non portable program construct > > for which the standard imposes no requirements, > > is what the standard says yields undefined behavior. > > But it doesn't say that *all* uses of nonportable program constructs > yield undefined behavior. > > Let's make it a complete program: > > int main(void) { > int n = 32767; > n ++; > return 0; > } > > I say that this program (specifically its execution) has undefined > behavior under an implementation with INT_MAX == 32767, and has > well defined behavior under an implementation with INT_MAX > 32767. > > What do you say? Are you claiming that the program's behavior is > undefined regardless of the implementation? Yes. That's an example of a non portable construct for which the standard imposes no requirements. -- pete