Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!genrad!panda!talcott!harvard!seismo!vrdxhq!rlgvax!hadron!jsdy From: jsdy@hadron.UUCP (Joseph S. D. Yao) Newsgroups: net.lang.c Subject: Re: type cast in initializer Message-ID: <247@hadron.UUCP> Date: Mon, 10-Feb-86 12:22:44 EST Article-I.D.: hadron.247 Posted: Mon Feb 10 12:22:44 1986 Date-Received: Thu, 13-Feb-86 17:35:58 EST References: <302@hsi.UUCP> <1450@bbncc5.UUCP> <232@hadron.UUCP> <1100@lsuc.UUCP> Reply-To: jsdy@hadron.UUCP (Joseph S. D. Yao) Organization: Hadron, Inc., Fairfax, VA Lines: 36 Summary: reply/explanation? In article <1100@lsuc.UUCP> msb@lsuc.UUCP (Mark Brader) writes: >In regard to... >> > > int x = 0; >> > > char *ptr = (char *) &x; >> > In any case, I'm not sure why you'd want to do what your example does, >> >since the cast here is a no-op. >Joseph S. D. Yao responds... >> Two reasons are immediately obvious... > >and goes on to give three reasons. Two are excellent, but the other is wrong: >> ... on some computer >> architectures, e.g. one with type-tagged pointers, the cast may >> [ NOTE: n o t "will", just "may" ] not be a no-op. (and this was the non-obvious, third reason.) >If this is not a slip, it stems from a misconception of casting which >is a Frequently Repeated Error in this newsgroup. ... >The cast specifies a conversion. ... >In the case of type-tagged pointers, the cast specifies that the >pointer tagged "int" is to be converted to one tagged "char" and >stored in the variable, but so would the initialization or assignment >without the cast, if the compiler accepts it at all. Perhaps this is my mistake, but I don't see what you have said that differs from mine. Yes, it specifies a conversion (if necessary). Therefore the cast may possibly not be a no-op. As you note, to even compile with some compilers, it may be required. Even if it is not required, however, then it is implicit and (possibly) not a no-op. The fact that it is required to be explicit on some machines and not cared about on others implies that you should use it if you desire that your code be more "portable". Does this explain why I say that it may not be a no-op? -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}