simple c99 compiler
git clone git://
Log | Files | Refs | Submodules | README | LICENSE

commit 62018c6c313a4b831976d23b71ed0e017cade6a2
parent 4c2f877eee5fe2730a7e51fc01861b7169bbbd47
Author: Roberto E. Vargas Caballero <>
Date:   Sat, 20 Aug 2022 20:03:49 +0200

README: Improve wording

MREADME | 59++++++++++++-----------------------------------------------
1 file changed, 12 insertions(+), 47 deletions(-)

diff --git a/README b/README @@ -91,10 +91,10 @@ It will generate the files sysld.h and sysincludes.h configured to be used with a musl libc. Beware that it is likely that those files have to be customized to fit your system because the macro GCCLIBPATH depends heavily of the toolchain used to compile musl. As the musl libc is likely -will be installed in a different prefix the scc compilation must be modified +installed in a different prefix the scc compilation must be modified to: - $ make LIBPREFIX=/usr/local/musl + $ make LIBPREFIX=/usr/local/musl # point to the prefix used by your musl If the helper scc shell script is used instead of scc-cc then the environment variable SCCLIBPREFIX must be set: @@ -104,45 +104,14 @@ environment variable SCCLIBPREFIX must be set: Deviations from standard C =========================== This compiler aims to be fully compatible with the C99 standard, but -it will have some differences: - -- Type qualifiers are accepted but ignored. - ----------------------------------------- - -Type qualifiers make the type system more complex and they add -unnecessary complexity to the compiler (and increased compilation time): - - - const: The definition of const is not clear in the standard. - If a const value is modified the behavior is undefined - behaviour. It seems it was defined in order to be able to - allocate variables in ROM rather than error detection. This - implememtation will not warn about these modifications and - the compiler will treat them like normal variables (the standard - specifies that a diagnostic message must be printed). - - - volatile: This qualifier was added to the standard - to be able to deal with longjmp (local variables that are not - volatile have undefined state) and for memory mapped registers - or variables whose values are modified asynchronously. This can - be achieved by using special pragma values though. - In the first case, it generates a lot of problems with modern - processors and multithreading, when not holding the value in a - register is not good enough (an explicit memory barrier is needed). - In the second case, this is non-portable code by definition - (depending on the register mapped), so it is better to deal with - it using another solution (compiler extensions or direct - assembly). Since it is needed for the correct behaviour - of portable programs that use longjmp, this specifier eventually - will be implemented. - - - restrict: This qualifier can only be applied to pointers that - mark the pointed object and has no other alias. This qualifier - was introduced to be able to fix some performance problems in - numerical algorithms, where FORTRAN could achieve a better - performance (and in fact even with this specifier FORTRAN has a - better performance in this field). Ignoring it doesn't make the - compiler non-standard and in almost all applications the performance - will be the same. +it has some differences at this moment: + +- Type qualifiers are accepted but partially ignored. + -------------------------------------------------- + +The semantic behind them is not fully implemented, specially in the +case of volatile. Be aware that some programs can miswork for this +reason. - Function type names ------------------- @@ -166,16 +135,12 @@ f(int g()) return g(); } -Function type names are stupid, because they are used as an alias -of the function pointer types, but it is stupid that something +Function type names seem unnecesary , because they are used as +an alias of the function pointer types, but it is weird that something like sizeof(int (int)) is not allowed (because here it should be understood as the size of a function), but f(int (int)) is allowed because it is understood as a parameter of function pointer type. -This complexity is not needed at all as function pointers fix all these -problems without this complexity (and they are the more common -way of writing such code). - - Definition of variables with incomplete type ---------------------------------------------