ckk@g.cs.cmu.edu (Chris Koenigsberg) (04/08/86)
I mentioned (article title "*p++ = *p and more")
that the PCC's on the Sun2 and the IBM RT PC treated "a[i]=b[i++]"
differently, and some people said I must have been mistaken. I dug up an
example program which displays the non-portability by printing different
results on the two machines. Try this on yours and see what you get!
Here is a short program displaying the problem:
*************
/* testing certain implementation-dependent features of compilers.
*/
#include <stdio.h>
main(argc, argv)
{char a[10];static char b[]="abcdefghij";int i,j;
printf("a =%s, b=%s\n", a, b);
printf("Looping over i...");
while(b[i] != 0) a[i] = b[i++];
printf("New a =");
for(i=0;i<=10;printf("%c",a[i++]));printf(", b=%s\n",b);
fflush(stdout);
}
**************
On a sun, the output looks like:
a =, b=abcdefghij
Looping over i...New a =abcdefghij^@, b=abcdefghij
**************
And on the IBM RT PC, the output looks like:
a =, b=abcdefghij
Looping over i...New a =^@abcdefghij, b=abcdefghij
**************
Note: The "^@" was actually a null character, in the output.
On the sun, a[0] gets b[0], but on the RT PC, a[1] gets b[0] and a[0] is
a null.
Chris Koenigsberg
ckk@g.cs.cmu.edu , or ckk%andrew@pt.cs.cmu.edu
{harvard,seismo,topaz,ucbvax}!g.cs.cmu.edu!ckk
(412)268-8526
Center for Design of Educational Computing
Carnegie-Mellon U.
Pgh, Pa. 15213jsdy@hadron.UUCP (Joseph S. D. Yao) (04/08/86)
In article <359@g.cs.cmu.edu> ckk@g.cs.cmu.edu (Chris Koenigsberg) writes: >#include <stdio.h> >main(argc, argv) > {char a[10];static char b[]="abcdefghij";int i,j; > printf("a =%s, b=%s\n", a, b); > printf("Looping over i..."); > while(b[i] != 0) a[i] = b[i++]; > printf("New a ="); > for(i=0;i<=10;printf("%c",a[i++]));printf(", b=%s\n",b); > fflush(stdout); > } >On a sun, the output looks like: >a =, b=abcdefghij >Looping over i...New a =abcdefghij^@, b=abcdefghij >And on the IBM RT PC, the output looks like: >a =, b=abcdefghij >Looping over i...New a =^@abcdefghij, b=abcdefghij >Note: The "^@" was actually a null character, in the output. >On the sun, a[0] gets b[0], but on the RT PC, a[1] gets b[0] and a[0] is >a null. Chris, run lint on this. One problem is that I IS NOT INITIALISED! Then, you index into a[10] both in the assignment and in the printing loops. Elements a[0-9] exist: a[10] is an addressing error. On the 8086, what model was this compiled under? You were lucky that this ran. (Yes, if core is zeroed first i will always be 0. What happens when you try to make this code a re-entrant subroutine?) As for the main point, this is working OK: the code does what people were saying it should do. I don't have your original message here: is this r e a l l y exactly what got folk upset?
jsdy@hadron.UUCP (Joseph S. D. Yao) (04/08/86)
In article <357@g.cs.cmu.edu>, ckk@g.cs.cmu.edu (Chris Koenigsberg) writes: > We ran into a similar problem with a section of code containing > "i=0; while(i<N) a[i] = b[i++];" > and we found that the Sun 120 4.2 C compiler decided that a[0] gets b[1], > while the IBM RT PC ACIS 4.2 C compiler decided that a[1] gets b[1] and a[0] > gets nothing (remains null, if it was initialized this way). In article <359@g.cs.cmu.edu> ckk@g.cs.cmu.edu (Chris Koenigsberg) writes: >On the sun, a[0] gets b[0], but on the RT PC, a[1] gets b[0] and a[0] is >a null. Note that one says a[1] <- b[1] and t'other says a[1] <- b[0] on the RT PC. Chris, now do you understand what folks were getting upset over? (Hint: the former.)