Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.chainon-marquant.org!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!74.125.46.80.MISMATCH!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: Wed, 16 Nov 2011 20:38:05 -0600 Message-ID: <4EC4738D.6D21@mindspring.com> Date: Wed, 16 Nov 2011 21:38:05 -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: when is typecasting (unsigned char*) to (char*) dangerous? References: <20111115125004.175@kylheku.com> <20111116094733.821@kylheku.com> <4EC41C0B.2040304@verizon.net> <4EC424E0.8060506@verizon.net> <033963f6-0c48-48f2-8cc8-161360fc7b76@r28g2000yqj.googlegroups.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Lines: 72 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 4.156.228.229 X-Trace: sv3-W1YtyrA8DcTfeOFqUcCK7YMP1Q0IueCowZWcapizziIrlWXYluU2rG2xedRQceMQd/01bRGww7zjv+R!NCmEMR2yAsZKGDq67ONmWnX8SFVho2xOvfKdSbJC//8IZGtkKpbcfUsPM8ioiGdpu3X1sLNBb3Uu!j2LmnrlBEJ8= 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: 4894 Xref: x330-a1.tempe.blueboxinc.net comp.lang.c:13536 =?UTF-8?Q?Harald_van_D=C4=B3k?= wrote: > > On Nov 17, 12:32 am, Keith Thompson wrote: > > Harald van Dijk writes: > > > On Nov 16, 10:02 pm, James Kuyper wrote: > > >> On 11/16/2011 03:41 PM, Harald van Dijk wrote: > > >> > On Nov 16, 9:24 pm, James Kuyper wrote: > > >> ... > > >> >> I know of no reason why signed char (and therefore, char) cannot have > > >> >> trap representations. However, every statement in 6.2.6.1p5 which says > > >> >> that the behavior is undefined when a trap representation is involved, > > >> >> explicitly excludes all character types, not just unsigned char. I'm not > > >> >> quite sure what to make of that fact, but I'm sure that explicitly > > >> >> excluding all character types was intentional; I'm not so sure whether > > >> >> it was intentional to allow signed char to have trap representations. > > > > >> > 6.2.6.1p5 refers to the trap representations for the type of the > > >> > object. In other words, if an object p of type void * holds a trap > > >> > representation, 6.2.6.1p5 makes it explicit that reading that object > > >> > as void * is not valid. > > > > >> So, in your opinion, what is the significance of the exclusion of > > >> character types from those statements? What do those statements mean, > > >> with those exclusions, that differs from what they would mean if those > > >> exclusions were dropped? Please accompany your explanation with specific > > >> examples of code that would have defined behavior under the existing > > >> rules, but not with that modification, or vice-versa. > > > > > If those exclusions were dropped, then using memcpy (or rather, a > > > custom function written in standard C that behaves exactly like > > > memcpy) to copy an object holding a trap representation would be > > > invalid. > > > > > /* the standard function memcpy, but implemented in 100% standard C */ > > > extern void *mymemcpy(void *dest, void *src, size_t n); > > > > > struct S > > > { > > >  int ptrIsValid; > > >  void *ptr; > > > }; > > > > > { > > >  struct S s1, s2; > > >  s2.ptrIsValid = 0; /* ptr is left uninitialised */ > > >  mymemcpy(&s1, &s2, sizeof(s1)); > > > } > > > > > Without the exclusion in 6.2.6.1p5, if pointer types can have trap > > > representations, mymemcpy would potentially use a character type to > > > read a trap representation. This should be allowed, and by excluding > > > character types in that paragraph, this is allowed. > > > > memcpy() can just use unsigned char, which is guaranteed not to have > > padding bits or trap representations. > > Yes, but that was not the point I was trying to make. I'm reading > s2.ptr, which potentially holds a trap representation, and 6.2.6.1p5 > disallows reading trap representations. It doesn't refer to > representations that do not represent a value in the type of the > lvalue expression, it refers to representations that do not represent > a value in the type of the object. The object has type void *, even if > it's accessed using unsigned char. That's why there needs to be a > specific exception for when the lvalue expression has character type. Pointers to character types have problems with neither size nor alignment of the bytes that they point to. -- pete