mike@ames.UUCP (04/08/87)
<eat this line dammit!! I dare ya!>
I created the following cortex numbing piece of code, and tried to
compile it under Aztec 3.4:
main()
{
int snickers[10];
int i=0;
snickers[i]=0;
}
After the compile, Aztec launched itself unrestrained into the assembler,
and promptly called up Mr. Guru (can you spell "crash"?). Replacing
the "i" with an actual integer such as 0 or 1 would work ok.
I changed the array to other types, but it would still behave just as
rudely.
Anybody have the same problem?? I know that using arrays is not a terribly
exotic technique, but I'm surprised nobody else has reported this.
I did install the two patches with no improvement, and did hand a printout
to Jim the II at last BAADG meeting.
*****************
And now for something completely different. . .
Tim Jennison (sp ?) of DigiView fame showed off DigiPaint at last night's
FAUG meeting. WOW!!
And to think, Jay felt that Hold-and-Modify was a useless gimmick that he
almost removed from his chips.
*****************
And for all those complaining about the A500's one piece box, Jay Miner told me
that one of his last acts as Amiga Prez was to try to talk C= out of the new
package, particularly since the A1000 box cost only about 10 bucks more.
****************
There was some discussion regarding enhanced graphics boards for the A2000
using the new chips, and super-hi-rez color, etc (the usual dreams) and
one voice from the back (couldn't identify who it was) said that we should
be patient for a little while, but he wasn't at liberty to say why.
****************
It was also announced last night that at the next meeting, A-squared would
be making an announcement that we would all like. Roomer time!
****************
da-da-da-dadada-dada-dat's all ffffolks!
--
*** mike (powered by M&Ms) smithwick ***
"every felt like life was a game, and
someone gave you the wrong instruction book?"dillon@CORY.BERKELEY.EDU.UUCP (04/09/87)
:compile it under Aztec 3.4:
: main()
: {
: ... (the snickers[] code)
: }
:
:After the compile, Aztec launched itself unrestrained into the assembler,
:and promptly called up Mr. Guru (can you spell "crash"?).
It doesn't happen to me. What are the particulars on the enviroment
that you are using (e.g. cc options, SET enviroment variables, etc...)??
-Mattrico@oscvax.UUCP (04/10/87)
Bug? What bug? Works fine for me... Assembles fine too... Maybe that
copy of the compiler is broken? There were two patches mentioned in the
original article, I've only seen one... what's the other one? Maybe it
caused the problem?
main()
{
int snickers[10];
int i=0;
snickers[i] = 0;
}
--------
;:ts=8
public _main
_main:
link a5,#.2
movem.l .3,-(sp)
clr.w -22(a5)
move.w -22(a5),d0
ext.l d0
asl.l #1,d0
lea -20(a5),a0
clr.w (a0,d0.l)
.4
movem.l (sp)+,.3
unlk a5
rts
.2 equ -22
.3 reg
public .begin
dseg
end
-Rico
--
[NSA food: terrorist, cryptography, DES, drugs, CIA, secret, decode]
[CSIS food: supermailbox, tuna, fiberglass coffins, Mirabel, microfiche]
[Cat food: Nine Lives, Cat Chow, Meow Mix, Crave]mike@ames.UUCP (Mike Smithwick) (04/13/87)
In article <481@oscvax.UUCP> rico@oscvax.UUCP (Rico Mariani) writes: > >Bug? What bug? Works fine for me... Assembles fine too... Maybe that >copy of the compiler is broken? There were two patches mentioned in the >original article, I've only seen one... what's the other one? Maybe it >caused the problem? Both my copies, and those of a friend of mine failed, using the unpatched and patched versions. Another local tried it, and his failed as well. Anyway, the latest patch posted by Jim, (number 3) fixes things and supercedes the previous 2 (patch 2 itself had bugs in it!!). 3.4a had so many little things wrong with it, that I hear their about ready to switch over to 3.4b. -- *** mike (powered by M&Ms) smithwick *** "every felt like life was a game, and someone gave you the wrong instruction book?"
kaz@cadovax.UUCP (04/14/87)
[]
Could someone please email me the 3 patches to the aztec 3.4 compiler?
Thanks in advance
Kerry Zimmerman
# {ucbvax,ihnp4,decvax}!trwrb!cadovax!kaz
# cadovax!kaz@ucla-locus.arpawalton@tybalt.caltech.edu.UUCP (04/15/87)
Here you go, Netlanders--hot off the Aztec West Coast BBS, 1-415-339-2427.
/*
* Aztec C68K/Am PATCH program v 1.3 - 4/2/87
*
* This program provides patches which fix bugs in the 3.4a version
* of the Aztec C68K system.
*/
/*
* 1) A statement of the form: < array[index] op= > will sometimes generate
* incorrect code which will modify the wrong address in memory.
*
* 2) A multiplication/division/modulo operation involving CHAR types
* within a conditional statement generates incorrect code.
* (Patch fixed in v 1.2)
*
* 3) Some bit field operations used the "lsr" instruction instead of the
* "ror" instruction.
*
* 4) The abs() routine is incorrectly being detected by the 68881 code
* generation.
*
* 5) In AS, a null pointer is sometimes used.
*
* 6-9) Fix AddGList function in cXXX.lib.
*
* 10-13) Fix NewModifyProp function in cXXX.lib.
*
*/
short patch1[] = {0x2f2a, 0x0006, 0x2f07, 0x2f2a, 0x0006, 0x487a,
0x057f, 0x4eac, 0x8320, 0x422c, 0x9412, 0x2f2a,
0x0006, 0x4eac, 0x825a, 0x4fef, 0x0014};
short patch2[] = {0x246d, 0x0008, 0x3012, 0xc07c, 0x00ff, 0x43ec,
0x8d62, 0x0831, 0x0005, 0x0000, 0x6604, 0x4a45,
0x6758, 0x3f05, 0x2f2a, 0x0012, 0x6158, 0x3800,
0x2eaa, 0x000e, 0x6150, 0x5c4f, 0xc840, 0x6742,
0x3f05, 0x2f2a, 0x0012, 0x4eba, 0x0206, 0x5c4f,
0x2540, 0x0012, 0x3f05, 0x2f2a, 0x000e};
short patch3[] = {0x006c, 0x736c, 0x0072, 0x6f72};
short patch4[] = {0x5a7a, 0x5a00};
short patch5[] = {0x2008, 0x6730, 0x4a28, 0x000c, 0x662a, 0x302a,
0x0006, 0xc07c, 0x00cf, 0xb07c, 0x0040, 0x6608};
short patch6[] = {0x0008, 0x4cef, 0x0403, 0x0010};
short patch10[] = {0x0010, 0x4cef, 0x003f, 0x001c};
struct patches {
short size;
long offset;
short *patch;
char *program;
long check;
char *chkstr;
} patches[] = {
sizeof(patch1), 0xb564, patch1, "cc", 0x357f, "3.4a",
sizeof(patch2), 0xf2de, patch2, "cc", 0x357f, "3.4a",
sizeof(patch3), 0xe514, patch3, "cc", 0x357f, "3.4a",
sizeof(patch4), 0x10a78, patch4, "cc", 0x357f, "3.4a",
sizeof(patch5), 0x83a2, patch5, "as", 0x6202, "3.4a",
sizeof(patch6), 0xdf4e, patch6, "c.lib", 0xdf08, "jgaddglist",
sizeof(patch6), 0xe156, patch6, "c32.lib", 0xe110, "jgaddglist",
sizeof(patch6), 0xe2a4, patch6, "cl.lib", 0xe25c, "jgaddglist",
sizeof(patch6), 0xe66c, patch6, "cl32.lib", 0xe624, "jgaddglist",
sizeof(patch10), 0xf381, patch10, "c.lib", 0xf334, "jgnewmodif",
sizeof(patch10), 0xf589, patch10, "c32.lib", 0xf53c, "jgnewmodif",
sizeof(patch10), 0xf6f3, patch10, "cl.lib", 0xf6a4, "jgnewmodif",
sizeof(patch10), 0xfabb, patch10, "cl32.lib", 0xfa6c, "jgnewmodif",
0
};
main()
{
int fd;
struct patches *pp;
char buf[80];
for (pp=patches;pp->size;pp++) {
printf("Applying patch %d ", pp-patches+1);
if ((fd = open(pp->program, 2)) < 0) {
printf("\nError opening program file <%s>, skipping ...\n",
pp->program);
continue;
}
printf("to <%s>\n", pp->program);
lseek(fd, pp->check, 0);
read(fd, buf, strlen(pp->chkstr));
buf[strlen(pp->chkstr)] = 0;
if (strcmp(buf, pp->chkstr)) {
printf("Error: program is not the correct version");
printf("skipping ...\n");
close(fd);
continue;
}
lseek(fd, pp->offset, 0);
write(fd, pp->patch, pp->size);
close(fd);
}
}vanam@pttesac.UUCP (Marnix van Ammers) (04/17/87)
In article <1478@cadovax.UUCP> kaz@cadovax.UUCP (Kerry Zimmerman) writes: >[] > >Could someone please email me the 3 patches to the aztec 3.4 compiler? > Sorry if this was posted before. I didn't see it and I'm sure lots of Manx users would like to have it. Here is program patch.c which will patch Manx's (3.40a) cc, as, c.lib, c32.lib, cl.lib, and cl32.lib. This was put on Manx's bulletin board by Jim Goodnow. Compile this program and run the executable in a directory where you've put the to-be-patched files. Marnix --- # This is a shell archive. # Remove everything above and including the cut line. # Then run the rest of the file through sh. #----cut here-----cut here-----cut here-----cut here----# #!/bin/sh # shar: Shell Archiver # Run the following text with /bin/sh to create: # patch.c # This archive created: Thu Apr 16 19:39:02 1987 cat << \SHAR_EOF > patch.c /* * Aztec C68K/Am PATCH program v 1.3 - 4/2/87 * * This program provides patches which fix bugs in the 3.4a version * of the Aztec C68K system. */ /* * 1) A statement of the form: < array[index] op= > will sometimes generate * incorrect code which will modify the wrong address in memory. * * 2) A multiplication/division/modulo operation involving CHAR types * within a conditional statement generates incorrect code. * (Patch fixed in v 1.2) * * 3) Some bit field operations used the "lsr" instruction instead of the * "ror" instruction. * * 4) The abs() routine is incorrectly being detected by the 68881 code * generation. * * 5) In AS, a null pointer is sometimes used. * * 6-9) Fix AddGList function in cXXX.lib. * * 10-13) Fix NewModifyProp function in cXXX.lib. * */ short patch1[] = {0x2f2a, 0x0006, 0x2f07, 0x2f2a, 0x0006, 0x487a, 0x057f, 0x4eac, 0x8320, 0x422c, 0x9412, 0x2f2a, 0x0006, 0x4eac, 0x825a, 0x4fef, 0x0014}; short patch2[] = {0x246d, 0x0008, 0x3012, 0xc07c, 0x00ff, 0x43ec, 0x8d62, 0x0831, 0x0005, 0x0000, 0x6604, 0x4a45, 0x6758, 0x3f05, 0x2f2a, 0x0012, 0x6158, 0x3800, 0x2eaa, 0x000e, 0x6150, 0x5c4f, 0xc840, 0x6742, 0x3f05, 0x2f2a, 0x0012, 0x4eba, 0x0206, 0x5c4f, 0x2540, 0x0012, 0x3f05, 0x2f2a, 0x000e}; short patch3[] = {0x006c, 0x736c, 0x0072, 0x6f72}; short patch4[] = {0x5a7a, 0x5a00}; short patch5[] = {0x2008, 0x6730, 0x4a28, 0x000c, 0x662a, 0x302a, 0x0006, 0xc07c, 0x00cf, 0xb07c, 0x0040, 0x6608}; short patch6[] = {0x0008, 0x4cef, 0x0403, 0x0010}; short patch10[] = {0x0010, 0x4cef, 0x003f, 0x001c}; struct patches { short size; long offset; short *patch; char *program; long check; char *chkstr; } patches[] = { sizeof(patch1), 0xb564, patch1, "cc", 0x357f, "3.4a", sizeof(patch2), 0xf2de, patch2, "cc", 0x357f, "3.4a", sizeof(patch3), 0xe514, patch3, "cc", 0x357f, "3.4a", sizeof(patch4), 0x10a78, patch4, "cc", 0x357f, "3.4a", sizeof(patch5), 0x83a2, patch5, "as", 0x6202, "3.4a", sizeof(patch6), 0xdf4e, patch6, "c.lib", 0xdf08, "jgaddglist", sizeof(patch6), 0xe156, patch6, "c32.lib", 0xe110, "jgaddglist", sizeof(patch6), 0xe2a4, patch6, "cl.lib", 0xe25c, "jgaddglist", sizeof(patch6), 0xe66c, patch6, "cl32.lib", 0xe624, "jgaddglist", sizeof(patch10), 0xf381, patch10, "c.lib", 0xf334, "jgnewmodif", sizeof(patch10), 0xf589, patch10, "c32.lib", 0xf53c, "jgnewmodif", sizeof(patch10), 0xf6f3, patch10, "cl.lib", 0xf6a4, "jgnewmodif", sizeof(patch10), 0xfabb, patch10, "cl32.lib", 0xfa6c, "jgnewmodif", 0 }; main() { int fd; struct patches *pp; char buf[80]; for (pp=patches;pp->size;pp++) { printf("Applying patch %d ", pp-patches+1); if ((fd = open(pp->program, 2)) < 0) { printf("\nError opening program file <%s>, skipping ...\n", pp->program); continue; } printf("to <%s>\n", pp->program); lseek(fd, pp->check, 0); read(fd, buf, strlen(pp->chkstr)); buf[strlen(pp->chkstr)] = 0; if (strcmp(buf, pp->chkstr)) { printf("Error: program is not the correct version," "skipping ...\n"); close(fd); continue; } lseek(fd, pp->offset, 0); write(fd, pp->patch, pp->size); close(fd); } } SHAR_EOF # End of shell archive exit 0 -- Marnix (ain't unix!) A. van\ Ammers Work: (415) 545-8334 Home: (707) 644-9781 CEO: MAVANAMMERS:UNIX UUCP: {ihnp4|ptsfa}!pttesac!vanam CIS: 70027,70
mike@ames.UUCP (04/17/87)
In article <408@pttesac.UUCP> vanam@pttesac.UUCP (Marnix van Ammers) writes: >of Manx users would like to have it. Here is program patch.c which will >patch Manx's (3.40a) cc, as, c.lib, c32.lib, cl.lib, and cl32.lib. A word of caution! This patch supercedes the previous two patches. So use the original cc when running this program. -- *** mike (powered by M&Ms) smithwick *** "ever felt like life was a game, and someone gave you the wrong instruction book?"