Home AMX User Forum AMXForums Archive Threads Tips and Tricks

Known (or apparent) bugs - post yours here

2»

Comments

  • Nice solution

    Matt:

    Interesting that evaluating a literal string containing two more characters does not produce an error.

    I don't have time to try this, but what if there were double quotes around the single charater string?
  • REBUILD_EVENTREBUILD_EVENT Junior Member Posts: 127
    I remember having troubles one time, when I used lowercase letters AND words with different lengths at the same time like

    CASE 'on' :
    CASE 'off':

    but it's been a while since, and maybe I even mixed lower- and uppercase letters
  • mpullinmpullin Obvious Troll Account, Marked for Deletion Posts: 949
    case study
    B_Clements wrote:
    I don't have time to try this, but what if there were double quotes around the single charater string?
    case ':A': // no problems
    case 'A': // major system error
    case "'A'": // syntax error
    case cCONSTANT_VAR: // major system error
    case "cCONSTANT_VAR": // syntax error

    Since cases can't be variables (not even constants), it makes sense that the compiler balks when it sees a ".

    Yeah, this probably means that you can't have something like $0D,$0A (CRLF) as a case; but I'm willing to accept this as a limitation of a switch/case.
  • dchristodchristo Junior Member Posts: 177
    mpullin wrote:
    Since cases can't be variables (not even constants), it makes sense that the compiler balks when it sees a ".


    I've never had a problem using constants in a Case. This works fine for me:
    Char strPowerQueryCmd[]		=	'CR0'
    
    Switch (strLastCmd)
    {
    	Case strPowerQueryCmd: {}
    }
    

    --D
  • alexanboalexanbo Junior Member Posts: 282
    I'll just second the notion that you can use constants in switch cases as I do it all the time as well.
  • mpullinmpullin Obvious Troll Account, Marked for Deletion Posts: 949
    alexanbo wrote:
    I'll just second the notion that you can use constants in switch cases as I do it all the time as well.
    Oops, my fault. cCONSTANT_VAR was actually an integer. Too late to edit my post I take it. :-|
  • NMarkRobertsNMarkRoberts Junior Member Posts: 455
    stack_var integer array[] full of junk

    You can rely upon a stack_var integer to be initialised with the value zero, but a stack_var integer array will initialise full of junk.

    A local_var integer array or define_variable integer array appear to initialise full of zeros.
  • Joe HebertJoe Hebert Junior Member Posts: 2,159
    Any STACK_VAR array[] initializes with junk
    a stack_var integer array will initialise full of junk.
    Thanks for the heads up, this is good to know.

    I believe you can amend your find to say that any STACK_VAR array[] will initialize with junk. At least it did when I tested a CHAR array[] and LONG array[]. I assume all intrinsic data types will act the same way.
  • viningvining X Member Posts: 4,368
    Apparently, it doesn't matter where the single characters are, they can't be in the same switch/case with multicharacter strings. This code produces the Major System Error:

    Why does this work?
    else
    	  {
    	  stack_var char cErrorMsg [100] ;
    	  switch (itoa(nFDirReturn)) 
    	       {
    	       case '-12': {cErrorMsg = 'directory not loaded'} ;
    	       case '-10': {cErrorMsg = 'buffer too small'} ;
    	       case '-6' : {cErrorMsg = 'invalid parameter (i.e. Entry points beyond the end of the directory)'} ;
    	       case '-5' : {cErrorMsg = 'Disk I/O error'} ;
    	       case '-4' : {cErrorMsg = 'invalid directory path'} ;
    	       case '0'  : {cErrorMsg = 'directory empty or unkown directory error'} ;
    	       }
    	  nFnumFilesInDir = 0 ;
    	  sFFList[1].FileFolder = cErrorMsg ;
    	  sFFList[1].FFicon = 'file' ;
    	  fnClearDispFileList('ERROR','FDirError') ;
    

    Originally I had the case with the single char string '0' at the beginning of the Switch which didn't work for the reasons cited in previous posts but after NMarkRoberts informed me of the single char string at the begining of the Switch problem I subsequently placed the case '0' at the end and had no problems.

    Have you tried placing the CASE 'A', CASE 'B', CASE 'C' at the end of the Switch?
  • mpullinmpullin Obvious Troll Account, Marked for Deletion Posts: 949
    vining wrote:
    Why does this work?
    I'm not sure. One of the differences between your code and mine is that I have a default. I don't have time right now to check it out, but what happens if you add a default case to that code?
  • viningvining X Member Posts: 4,368
    This compiles fine w/ default added:
    else
    	  {
    	  stack_var char cErrorMsg [100] ;
    	  switch (itoa(nFDirReturn)) 
    	       {
    	       case '-12': {cErrorMsg = 'directory not loaded'} ;
    	       case '-10': {cErrorMsg = 'buffer too small'} ;
    	       case '-6' : {cErrorMsg = 'invalid parameter (i.e. Entry points beyond the end of the directory)'} ;
    	       case '-5' : {cErrorMsg = 'Disk I/O error'} ;
    	       case '-4' : {cErrorMsg = 'invalid directory path'} ;
    	       case '0'  : {cErrorMsg = 'directory empty or unkown directory error'} ;
    	       default:    {cErrorMsg = 'no known error number matches'} ;
    	       }
    	  nFnumFilesInDir = 0 ;
    	  sFFList[1].FileFolder = cErrorMsg ;
    	  sFFList[1].FFicon = 'file' ;
    

    This does not. Added case '1': in the middle of the switch. "Major systems error....."
    else
    	  {
    	  stack_var char cErrorMsg [100] ;
    	  switch (itoa(nFDirReturn)) 
    	       {
    	       case '-12': {cErrorMsg = 'directory not loaded'} ;
    	       case '-10': {cErrorMsg = 'buffer too small'} ;
    	       case '1'  : {cErrorMsg = 'directory empty or unkown directory error'} ;
    	       case '-6' : {cErrorMsg = 'invalid parameter (i.e. Entry points beyond the end of the directory)'} ;
    	       case '-5' : {cErrorMsg = 'Disk I/O error'} ;
    	       case '-4' : {cErrorMsg = 'invalid directory path'} ;
    	       case '0'  : {cErrorMsg = 'directory empty or unkown directory error'} ;
    	       default:    {cErrorMsg = 'no known error number matches'} ;
    	       }
    	  nFnumFilesInDir = 0 ;
    	  sFFList[1].FileFolder = cErrorMsg ;
    	  sFFList[1].FFicon = 'file' ;
    

    Moving the case '1' : to the bottom compiles fine.
     else
    	  {
    	  stack_var char cErrorMsg [100] ;
    	  switch (itoa(nFDirReturn)) 
    	       {
    	       case '-12': {cErrorMsg = 'directory not loaded'} ;
    	       case '-10': {cErrorMsg = 'buffer too small'} ;
    	       case '-6' : {cErrorMsg = 'invalid parameter (i.e. Entry points beyond the end of the directory)'} ;
    	       case '-5' : {cErrorMsg = 'Disk I/O error'} ;
    	       case '-4' : {cErrorMsg = 'invalid directory path'} ;
    	       case '0'  : {cErrorMsg = 'directory empty or unkown directory error'} ;
    	       case '1'  : {cErrorMsg = 'directory empty or unkown directory error'} ;
    	       default:    {cErrorMsg = 'no known error number matches'} ;
    	       }
    	  nFnumFilesInDir = 0 ;
    	  sFFList[1].FileFolder = cErrorMsg ;
    	  sFFList[1].FFicon = 'file' ;
    

    This also works:
     else
    	  {
    	  stack_var char cErrorMsg [100] ;
    	  switch (itoa(nFDirReturn)) 
    	       {
    	       case '-12': {cErrorMsg = 'directory not loaded'} ;
    	       case '-10': {cErrorMsg = 'buffer too small'} ;
    	       case '-6' : {cErrorMsg = 'invalid parameter (i.e. Entry points beyond the end of the directory)'} ;
    	       case '-5' : {cErrorMsg = 'Disk I/O error'} ;
    	       case '-4' : {cErrorMsg = 'invalid directory path'} ;
    	       case '0'  : {cErrorMsg = 'directory empty or unkown directory error'} ;
    	       case '1'  : {cErrorMsg = 'directory empty or unkown directory error'} ;
    	       case 'A'  : {cErrorMsg = 'TestA'} ;
    	       case 'B'  : {cErrorMsg = 'TestB'} ;
    	       default:    {cErrorMsg = 'no known error number matches'} ;
    	       }
    	  nFnumFilesInDir = 0 ;
    	  sFFList[1].FileFolder = cErrorMsg ;
    

    It appears single char string CASES can't be placed before multiple char string CASES. I remember the post NMarkRoberts wrote when I had my similar problem and I beleive he said it a single char string CASE couldn't be the first CASE and of course I just went straight to the end. Maybe they just can't be before any multiple string CASES. I can't imagine why other that a compiler bug.
  • NMarkRobertsNMarkRoberts Junior Member Posts: 455
    Repeating what I said a week ago:

    switch(s)
    {
    //case 'a': (* Causes major system error *)
    case 'cc': (* Has to be there *)
    {
    }
    }
  • REBUILD_EVENTREBUILD_EVENT Junior Member Posts: 127
    multiple combine_devices

    we did accidentally two COMBINE_DEVICES(vdvtp,dvtp1,dvtp2) on two connected controllers. we combined the same devices two times. the result was, that both controllers hung, with their "Input" LED permanently on istead of flashing
  • viningvining X Member Posts: 4,368
    I don't follow what you're saying below! What is "(* Has to be there *)"? Are you saying that CASE 'cc': has to be after CASE 'a': for the code to work? I'm not talking compiling!

    NMarkRoberts wrote:
    [Repeating what I said a week ago:

    switch(s)
    {
    //case 'a': (* Causes major system error *)
    case 'cc': (* Has to be there *)
    {
    }

    Are you sure you weren't trying to reference this line?

    NMarkRoberts wrote ealier in this thread:
    So you just have to put the single character cases at the end of the list, or use something other than switch/case.
  • NMarkRobertsNMarkRoberts Junior Member Posts: 455
    vining wrote:
    I don't follow what you're saying below!

    A single character case causes a major system error, but only if there is a multiple character case after it in the list.
  • Stephen BoltonStephen Bolton Junior Member Posts: 345
    G4 panel webcontrol name can cause webserver crash

    If you place and ampersand in a G4 panels webcontrol name, the webserver in the master with 3.21.343 firmware will fall over.

    Tested on NI 3000 running 3.21.343 (previous f/w NOT tested)
    MVP 8400 running 2.70.8

    There are other characters that cause this problem, but I have not confirmed them all.

    I will try to post a more exhaustive list later.
  • NMarkRobertsNMarkRoberts Junior Member Posts: 455
    Another "Major System Error"

    This code illustrates a compiler problem.
    program_name = 'fred'
    
    define_device 
    
    dTelnetServer = 0:first_local_port + 1:0
    
    define_start
    
    send_string dTelnetServer,'fred'
    

    If you try to compile it you get a "Major System Error" which goes away either if you remove the send_string or if you declare the device in some other way, that is, without using "first_local_port + 1" in the declaration, eg dTelnetServer = 0:3:0.

    It seems that you may use the device in many other ways, just not a send_string.
  • DHawthorneDHawthorne Old Timer Posts: 4,584
    This code illustrates a compiler problem.
    program_name = 'fred'
    
    define_device 
    
    dTelnetServer = 0:first_local_port + 1:0
    
    define_start
    
    send_string dTelnetServer,'fred'
    

    If you try to compile it you get a "Major System Error" which goes away either if you remove the send_string or if you declare the device in some other way, that is, without using "first_local_port + 1" in the declaration, eg dTelnetServer = 0:3:0.

    It seems that you may use the device in many other ways, just not a send_string.

    No, the problem is you are trying to do arithmetic on a system constant that hasn't been resolved yet. FIRST_LOCAL_PORT has no value at the time of variable declaration (I'm not sure if it's zero or NULL though), and the compiler's problem is with trying to add to a value that doesn't exist. If you didn't have the +1 on there, it would work because you are just declaring the memory space, and it gets filled in later. It would also work if you just declared empty device variables, and then used FIRST_LOCAL_PORT + 1, etc., in DEFINE_START to populate them.
  • NMarkRobertsNMarkRoberts Junior Member Posts: 455
    DHawthorne wrote:
    No, the problem is you are trying to do arithmetic on a system constant that hasn't been resolved yet.

    The problem is that the compiler doesn't say that, it says "Major System Error".
  • REBUILD_EVENTREBUILD_EVENT Junior Member Posts: 127
    VOLATILE INTEGER nTest;
    VOLATILE INTEGER nTest2[20];
    
    IF(nTest==nTest2)
    		{
    		// do nothing
    		}
    
    
    This compiles smoothly but IMHO does not make any sense. I would be pleased if the AMX guys could introduce a truckload of Compiler Warning Messages (that make sense). Other compilers even allow to set the verbosity of the compiler.
  • travtrav Get off my lawn Posts: 188
    Just to quote your message from a few lines up, as I'm too lazy to swap back and forth....

    [php]
    program_name = 'fred'

    define_device

    dTelnetServer = 0:first_local_port + 1:0

    define_start

    send_string dTelnetServer,'fred'
    [/php]

    If you try to compile it you get a "Major System Error" which goes away either if you remove the send_string or if you declare the device in some other way, that is, without using "first_local_port + 1" in the declaration, eg dTelnetServer = 0:3:0.

    Apart from sending a string to an ip connection you haven't opened /=) (I know I know) It seems to me that this is another time when using firstlocalport has a few caveats attached, such as:

    [php]
    DEFINE EVENT

    //For some reason using the explicate DPS doesn't work....
    //Gives you a major system error
    DATA_EVENT[dTelnetServer]
    {
    STRING:
    {
    // This doesn't work properly
    }
    }

    //But directly referencing the port does.....
    DATA_EVENT[dTelnetServer.port]
    {
    STRING:
    {
    // This works properly
    }
    }
    [/php]

    The first one gives you the same character in a military sitcom as Marks send_string to just dTelnetServer. This only appears to be of note when useing

    dTelnetServer = 0:FIRST_LOCAL_PORT+1:0

    Any incrementation on your ports causes this, just using FIRST_LOCAL_PORT (which defeats the whole purpose of being able to dynamically allocate ports in this way) works.

    So as tested, this will work in the send_string case :

    [php]
    DEFINE_START

    //This works.....
    SEND_STRING dTelnetServer.PORT,"'I LIKE BEER!!'"
    [/php]

    Interesting behaviour, probably along the lines of the affor mentioned undefined constant, but then why does the .PORT work..... oh well, it does.

    **EDIT** I use the php formating as I like the colours.... perhaps they can just edit the template so it reads AMX instead ^_^
Sign In or Register to comment.