Difference between revisions of "AMOS:Bugs"

From Amiga Coding
Jump to: navigation, search
(many if's -> many *else*if's causes problems with the compiler)
(more bug stuff)
Line 4: Line 4:
  
  
==Using the Input command with a too long text==
+
==Various==
(Discovered by Spellcoder, somewhere before 2000)<br />
+
* [[AMOS:bug Input|if text from Input command reacher right side of screen, AMOS will freeze for a while]]
  
If you use a text that's so long it'll reach the end of the screen, AMOS(Pro) will hang for a while.
 
How long the text needs to be for this to happen seems to depend on the width of the screen.
 
  
Screen Open 0,320,200,4,Lowres
+
==Math bugs==
Input "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!?";A$
+
* [[AMOS:bug Mod|remainder of mod should be negative if given number is negative]]<br />When in R=V mod D, R is a negative number, the resulting number should be <1. However the result is allways positive.<br />(tested in AMOSPro V2.00, with integers and floating-point numbers)
  
This example uses 38 chars (so it's 38*8 pixels = 304 pixels width).<br />
 
The cursor is also 8 pixels (304+8=312).<br />
 
  
(not tested yet if it happens earlyer if you place the cursor in the middle of the screen)
+
==Editor bugs==
  
 
+
* Editor will change %111111111111111111111111111111111 (33 bits) into 1111111111<br />(Discovered by Spellcoder, 24 sep 2007)<br />
 
+
<br />33 bits will overflow AMOS's 32 bits numers, but why it changes the numer into 1111111111 I can't fanthom.
==Can't write %111111111111111111111111111111111==
 
(Discovered by Spellcoder, 24 sep 2007)<br />
 
 
 
If you write %111111111111111111111111111111111, AMOS will change it in 10
 

Revision as of 20:58, 28 September 2007

Compiler bugs

  • many elseif's causes problems with the AMOS(Pro) compiler?
  • many data statements causes problems with the AMOS(Pro) compiler?


Various


Math bugs


Editor bugs

  • Editor will change %111111111111111111111111111111111 (33 bits) into 1111111111
    (Discovered by Spellcoder, 24 sep 2007)


33 bits will overflow AMOS's 32 bits numers, but why it changes the numer into 1111111111 I can't fanthom.