# HG changeset patch
# User Mario de Sousa <msousa@fe.up.pt>
# Date 1346086687 -3600
# Node ID ffa02cf2b3359bbe7d71b57472d80d75f442d880
# Parent  c2546c6e0cfa5ad55b288895f17f1b9f2a228f3b
Add some comments.

diff -r c2546c6e0cfa -r ffa02cf2b335 stage3/constant_folding.cc
--- a/stage3/constant_folding.cc	Fri Aug 17 19:03:13 2012 +0100
+++ b/stage3/constant_folding.cc	Mon Aug 27 17:58:07 2012 +0100
@@ -32,6 +32,16 @@
 
 
 
+/* TODO: 
+ *         - Add support for comparison (= and !=) of enumeration literals!
+ *              We will need to add another const_value entry to the symbol_c, containing the 
+ *              possible enumeration value of the enum constant!
+ *              Doing this will allow us to more easily implement a constant_propagation_c later on!
+ *
+ *         - Add support for comparison (= and !=) of the exact same variable
+ *                (e.g. if (int_v = int_v) then ...)
+ */
+
 
 
 /* Do constant folding...
@@ -215,7 +225,11 @@
    * by having it resolve the call to the overloaded function. For the C++ compiler to be able
    * to resolve this ambiguity, we need to add a dummy parameter to each function!
    *
-   * TODO: support platforms in which int64_t is mapped onto int !! Is this really needed?
+   * TODO: support platforms (where the compiler will run) in which int64_t is mapped onto int !!
+   *       Is this really needed?
+   *       Currently, when trying to compile matiec on sych a platform, the C++ compiler will not
+   *       find any apropriate matiec_strtoint64() to call, so matiec will not be able to be compiled.
+   *       If you need this, you are welcome to fix it yourself...
    */
 static  int64_t matiec_strtoint64 (         long      int *dummy, const char *nptr, char **endptr, int base) {return strtol  (nptr, endptr, base);}
 static  int64_t matiec_strtoint64 (         long long int *dummy, const char *nptr, char **endptr, int base) {return strtoll (nptr, endptr, base);}
@@ -544,6 +558,11 @@
 /* unary negation (multiply by -1) */
 static void *handle_neg(symbol_c *symbol, symbol_c *oper) {
 	DO_UNARY_OPER( int64, -, oper);	CHECK_OVERFLOW_int64_NEG(symbol, oper);
+	/*
+	 * NOTE : The syntax:   uint_v := -<INT_MIN>  may occur inside a neg_expression_c, but would always
+	 *        result in a data type error (in-> INT, out -> UINT). So, although we could handle it here, 
+	 *        it is not really necessary as it will later be caught by the data type checking classes.
+	 */
 	DO_UNARY_OPER(real64, -, oper);	CHECK_OVERFLOW_real64(symbol);
 	return NULL;
 }
@@ -755,6 +774,18 @@
 	if (VALID_CVALUE(uint64, symbol->exp) && (GET_CVALUE(uint64, symbol->exp) == (uint64_t)INT64_MAX+1)) {
 		SET_CVALUE(int64, symbol, INT64_MIN);
 	}
+	/* NOTE 3: The standard allows considers the following strange syntax correct:
+	 *            int_v = ----------42;
+	 *         However, it will be parsed as multiple neg_expression_c, with a single final neg_integer_c.
+	 *         So, when parsing a neg_integer_c, we are guaranteed to always have a positive value in symbol->exp
+	 *         --> Conclusion: 
+	 *         We do not need to handle the situation where we are negating the INT_MIN value, whose
+	 *         result can only be stored inside an UINT (remember that INT_MIN is < 0 !!).
+	 *
+	 * NOTE 4: The syntax:   uint_v := -<INT_MIN>  may occur inside a neg_expression_c, but would always
+	 *         result in a data type error. So, although we could handle it here, it is not really
+	 *         necessary as it will later be caught by the data type checking classes.
+	 */
 	return NULL;
 }