README (3511B)
1 Derivations from standard C 2 =========================== 3 This compiler is aimed to be being fully compatible with the C99 standard, but 4 it will have some differences: 5 6 - Type qualifiers are accepted but ignored. 7 ----------------------------------------- 8 9 Type qualifers make the type system ugly, and their uselessness add 10 unnecessary complexity to the compiler (and increased compilation time): 11 - const: The definition of const is not clear in the standard. 12 If a const value is modified the behaviour is undefined 13 behaviour. It seems it was defined in order to be able to 14 allocate variables in ROM rather than error detection. This 15 implememtation will not warn about these modifications and 16 the compiler will treat them like normal variables (the standard 17 specifies that a diagnostic message must be printed). 18 19 - volatile: This qualifier was added to the standard 20 to be able to deal with longjmp (local variables that are not 21 volatile have undefined state) and for memory mapped registers 22 or variables whose values are modified asynchronously. This can 23 be achieved with special pragma values though. 24 In the first case, it generates a lot of problems with modern 25 processors and multithreading, where not holding the value in a 26 register is not good enough (an explicit memory barrier is needed). 27 In the second case, this is non-portable code by definition 28 (depending on the register mapped), so it is better to deal with 29 it using another solution (compiler extensions or direct 30 assembler). 31 32 - restrict: This qualifer can only be applied to pointers to 33 mark that the pointed object has no other alias. This qualifer 34 was introduced to be able to fix some performance problems in 35 numerical algorithms, where FORTRAN could achieve a better 36 performance (and in fact even with this specifier FORTRAN has a 37 better performance in this field). Ignoring it doesn't make the 38 compiler non-standard and in almost all applications the performance 39 will be the same. 40 41 - Function type names 42 ------------------- 43 44 C99 allows you to define type names of function types and write something 45 like: 46 47 int f(int (int)); 48 49 Accepting function types in typenames (or abstract declarators) makes the 50 grammar ambiguous because it is impossible to differentiate between: 51 52 (int (f)) -> function returning int with one parameter of type f 53 (int (f)) -> integer variable f 54 55 If you don't believe me try this code: 56 57 int 58 f(int g()) 59 { 60 return g(); 61 } 62 63 Function type names are stupid, because they are used as an alias 64 of the function pointer types, but it is stupid that something 65 like sizeof(int (int)) is not allowed (because here it should be 66 understood as the size of a function), but f(int (int)) is allowed 67 because it is understood as a parameter of function pointer type. 68 69 This complexity is not needed at all as function pointers fix all these 70 problems without this complexity (and they are the more usual 71 way of writing such code). 72 73 - Definition of variables with incomplete type 74 --------------------------------------------- 75 76 C89 allows the definition of variables with incomplete type that 77 have external linkage and file scope. The type of the variable 78 is the composition of all the definitions find in the file. The exact 79 rules are a bit complex (3.7.2), and SCC ignores them at this moment 80 and it does not allow any definition of variables with incomplete type. 81 82 If you don't believe me try this code: 83 84 struct foo x; 85 86 struct foo { 87 int i; 88 };