stage3/fill_candidate_datatypes.cc
changeset 911 ef3347dbfa0c
parent 909 8b2a31dea131
child 919 8da635655f37
equal deleted inserted replaced
910:a0518971127d 911:ef3347dbfa0c
  1859 /***********************/
  1859 /***********************/
  1860 /* B 3.1 - Expressions */
  1860 /* B 3.1 - Expressions */
  1861 /***********************/
  1861 /***********************/
  1862 /* SYM_REF1(ref_expression_c, exp)  --> an extension to the IEC 61131-3 standard - based on the IEC 61131-3 v3 standard. Returns address of the varible! */
  1862 /* SYM_REF1(ref_expression_c, exp)  --> an extension to the IEC 61131-3 standard - based on the IEC 61131-3 v3 standard. Returns address of the varible! */
  1863 void *fill_candidate_datatypes_c::visit(  ref_expression_c  *symbol) {
  1863 void *fill_candidate_datatypes_c::visit(  ref_expression_c  *symbol) {
       
  1864   /* We must first determine the datatype of the expression passe to the REF() operator, with no ambiguities! 
       
  1865    * To do this, we could use the complete standard fill/narrow algorithm for determining the datatype
       
  1866    * of the expression. This is actually possible, as nothing stops us from directly calling the narrow_candidate_datatypes_c
       
  1867    * from this method inside fill_candidate_datatypes_c, to complete the fill/narrow algorithm on this
       
  1868    * expression only.
       
  1869    * However, for the moment we take a shortcut, and set the expression's "datatype" directly, even though this 
       
  1870    * should really only be done in narrow_candidate_datatypes_c. This is possible because the expression should be
       
  1871    * an lvalue (assuming source code has no bugs), with only one candidate datatype.
       
  1872    * 
       
  1873    * (We should really check whether the expression is an lvalue. For now, leave it for the future!)
       
  1874    * 
       
  1875    * Note, however, that array variables are also lvalues, and they may containg complex
       
  1876    * expressions that include function calls in their indexes. These complex expressions must therefore still be
       
  1877    * analysed using the standard fill/narrow algorithm...
       
  1878    */
  1864   symbol->exp->accept(*this);
  1879   symbol->exp->accept(*this);
  1865   /* we should really check whether the expression is an lvalue. For now, leave it for the future! */
  1880   if (symbol->exp->candidate_datatypes.size() == 1)
  1866   /* For now, we handle references (i.e. pointers) as ULINT datatypes! */
  1881     symbol->exp->datatype = symbol->exp->candidate_datatypes[0];
  1867   add_datatype_to_candidate_list(symbol, &get_datatype_info_c::ulint_type_name);
  1882 
       
  1883   /* Create a new object of ref_spec_c, as this is the class used as the canonical/base datatype of REF_TO types 
       
  1884    * (see search_base_type_c ...)
       
  1885    */ 
       
  1886   ref_spec_c *ref_spec = new ref_spec_c(symbol->exp->datatype);
       
  1887   add_datatype_to_candidate_list(symbol, ref_spec);
  1868   return NULL;
  1888   return NULL;
  1869 }
  1889 }
  1870     
  1890     
  1871 void *fill_candidate_datatypes_c::visit(   or_expression_c  *symbol) {return handle_binary_expression  (widen_OR_table,  symbol, symbol->l_exp, symbol->r_exp);}
  1891 void *fill_candidate_datatypes_c::visit(   or_expression_c  *symbol) {return handle_binary_expression  (widen_OR_table,  symbol, symbol->l_exp, symbol->r_exp);}
  1872 void *fill_candidate_datatypes_c::visit(   xor_expression_c *symbol) {return handle_binary_expression  (widen_XOR_table, symbol, symbol->l_exp, symbol->r_exp);}
  1892 void *fill_candidate_datatypes_c::visit(   xor_expression_c *symbol) {return handle_binary_expression  (widen_XOR_table, symbol, symbol->l_exp, symbol->r_exp);}