long@sask.UUCP (Warren Long) (05/30/87)
I have been porting some programs written to run on a SUN system to my atari with MWC v.2. I have discovered that: Part A: long int temp1; int m; ------ m= anything....; temp1 += m; ------- always leaves temp1 = 0; To try to solve this, I separated the statements: ------ m = anything....; temp1 = temp1 + m; ------ and ended up with the same results. Is this an illegal thing to do?? I assumed that types would be coersed into the correct thing. This works fine on SUN, ULTRIX and UNIX. Part B: In spite of several attempts, a few weeks apart, I still haven't gotten any file IO to work with MWC in the UNIX mode (ie. using integer file descriptors). In all cases, I have given up, and returned to the trusty FILE *fname. Is anybody else experiencing similar problems?? Warren Long -- =-=-=-=-=-Warren Long at University of Saskatchewan, Canada-=-=-=-=- Home: 78 Carleton Dr.,Saskatoon, Sasakatchewan, S7H 3N6 Phone: (306)-955-1237 =-=-=-=-=-U-Email: ...!ihnp4!alberta!sask!long -=-=-=-=-=-=-=-=-
mrd@clutx.BITNET.UUCP (06/17/87)
>From: ubc-vision!alberta!sask!long@beaver.cs.washington.edu (Warren Long) > >I have been porting some programs written to run on a SUN system to >my atari with MWC v.2. I have discovered that: > >long int temp1; >int m; >------ >m= anything....; >temp1 += m; >------- >always leaves temp1 = 0; >and ended up with the same results. Is this an illegal thing to do?? >I assumed that types would be coersed into the correct thing. This >works fine on SUN, ULTRIX and UNIX. (First off I do not own MWC. (yet)) This operation is not legal. In general it is usually advised that you do ALL type coersions in c. To quote KR page 184 section 6.6 "if either operand is long ... that is the type of the result" Therefor you are assigning a long to an int. On most large systems this is not a problem as both int and long ints are 32 bits so you get away with it. I assume that MWC ints are 16 bits. (I may be wrong about MWC ints but it doesn't matter) This can and will cause problems. If you have a unix box handy run lint on the programs. lint will complain. If you fix up the code so that lint doesn't complain, you should not have any problems. If you don't have lint see if MWC can be forced to complain when compiling the program; many of the new compilers for micros have a sort of lint built in (like turboc). MWC is not to be blamed for doing this, it is following KR faithfully at least on this point. Michael DeCorte mrd@clutx.clarkson.edu mrd@clutx.bitnet p.s. KR stands for Kernighan and Ritchie "The C Programming Language" of course.
dillon@CORY.BERKELEY.EDU.UUCP (06/17/87)
:I have been porting some programs written to run on a SUN system to :my atari with MWC v.2. I have discovered that: : :long int temp1; :int m; :------ :m= anything....; :temp1 += m; :------- :always leaves temp1 = 0; :and ended up with the same results. Is this an illegal thing to do?? :I assumed that types would be coersed into the correct thing. This :works fine on SUN, ULTRIX and UNIX. Perfectly legal. 'm' is automatically casted to a long before being added to temp1. -Matt
stephen@datacube.UUCP (06/18/87)
>>From: ubc-vision!alberta!sask!long@beaver.cs.washington.edu (Warren Long) >> >>I have been porting some programs written to run on a SUN system to >>my atari with MWC v.2. I have discovered that: >> >>long int temp1; >>int m; >>------ >>m= anything....; >>temp1 += m; >>------- >>always leaves temp1 = 0; >>and ended up with the same results. Is this an illegal thing to do?? >>I assumed that types would be coersed into the correct thing. This >>works fine on SUN, ULTRIX and UNIX. >This operation is not legal. Wrong. >"if either operand is long ... that is the type of the result" Correct. >Therefor you are assigning a long to an int. Wrong. He is assigning adding an int to a long and then assigning the LONG result to a LONG. Therefore, the originator of this note is correct, his compiler has a blatant bug. Please read a note carefully before giving out incorrect and/or misleading advice. Stephen Watkins UUCP: ihnp4!datacube!stephen Datacube Inc.; 4 Dearborn Rd.; Peabody, Ma. 01960; 617-535-6644
dclemans@mntgfx.MENTOR.COM (Dave Clemans) (06/18/87)
Mark Williams C version 2.0 has a bug in doing at least some types
of sign extensions of int's to longs; specifically it can generate
the 68000 instruction
ext.w
(which sign extends an 8 bit quantity into 16 bits) instead of
the correct
ext.l
(which sign extends a 16 bit quantity into 32 bits).
dgcat@laura.irb.informatik (Andreas Toenne) (06/21/87)
Hi, has anyone collected all known bugs in MWC 2.0 ?? I am quite happy with the old version (and I know all its bugs :-) but 2.0 is probably better. Andreas Toenne U of Dortmund, IRB West Germany at@unido.uucp at@unido.bitnet D
grr@cbmvax.cbm.UUCP (George Robbins) (06/26/87)
In article <52@laura.irb.informatik> at@unido.UUCP (Andreas Toenne) writes: > > has anyone collected all known bugs in MWC 2.0 ?? > I am quite happy with the old version (and I know all its bugs :-) > but 2.0 is probably better. > > Andreas Toenne U of Dortmund, IRB West Germany Although not widely advertised, MWC is on the net, at least as far as E-MAIL. Any bug reports, especially those regarding the C compiler may be directed to mwc!norm. UUCP: ...!ihnp4!mwc!norm ...!cbmvax!mwc!norm ARPA: cbmvax!mwc!norm@seismo.css.GOV Other paths are left to your imagination... -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)