ccc_ldo@waikato.ac.nz (02/20/90)
In <10311@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) says that (Str255 *) is a "nonsense" type. Perhaps this is true. I'm ready to give up trying to find a better answer. But before I do so, here's a final twist on the example. First, the appropriate variable declarations: Str255 temps, *tempp; unsigned char ch; int i; Now the two example expressions: ch = temps[i]; ch = (*tempp)[i]; Both of these generate virtually identical code. The only difference, apart from the reference to different variables, is that in the first expression, the index is treated as a word, while in the second expression, the index is a longword.
tim@hoptoad.uucp (Tim Maroney) (02/21/90)
In article <167.25e15b52@waikato.ac.nz> ccc_ldo@waikato.ac.nz writes: >In <10311@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) says that >(Str255 *) is a "nonsense" type. Perhaps this is true. I'm ready >to give up trying to find a better answer. Actually, John Gilmore, who follows the C standard, informs me that pointers to arrays have always been legal; the problem has been that the address operator had previously been defined as a no-op on arrays, where it should have given a value of the type pointer-to-array. The ANSI C standard fixes this so &array does produce pointer-to-array, and MPW C would appear to be noncompliant in this respect, since it uses the old no-op interpretation. If this is correct, your original code should have worked, and it only failed because of a non-compliance to the ANSI standard in MPW C. However, you can still avoid all these issues completely using the StringPtr solution I suggested. No funny type casts, either. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Every institution I've ever been associated with has tried to screw me." -- Stephen Wolfram