[M3commit] CVS Update: cm3

[Daniel Alejandro Benavides D.]

Hi all:
with all due respect this is what I warned about mixing RTs in one compiler, most unsafety of C in Modula-3 is not a good idea, good C ideas are indeed needed, e.g. Fail-Safe C, gcc will have a Fail-safe plugin, if c is what you want to, use it.
Jay I know of a way to ask old DEC-SRC Modula-3 -> C compiler, if you want even possibly asking the compiler in C, wouldn't that make the trick for us of compiling in AMD64_NT? We don't need to have the whole world in C to do that, do we? You could recompile itself and make a ready to boot compiler.
Thanks in advance

--- El sáb, 8/9/12, Jay Krell <jkrell at elego.de> escribió:

De: Jay Krell <jkrell at elego.de>
Asunto: [M3commit] CVS Update: cm3
Para: m3commit at elegosoft.com
Fecha: sábado, 8 de septiembre, 2012 06:24

CVSROOT:    /usr/cvs
Changes by:    jkrell at birch.    12/09/08 11:24:43

Modified files:
    cm3/m3-libs/m3core/src/float/C99/: FPU.i3 m3makefile 
Added files:
    cm3/m3-libs/m3core/src/float/C99/: FPU.c 
Removed files:
    cm3/m3-libs/m3core/src/float/C99/: FPU.m3 

Log message:
    implement FPU.scalb via FPU__ldexp, via a C wrapper,
    as is common now
    
    I caught this because the declaration is wrong here,
    int vs. INTEGER. The C backend causes an interesting
    interop feature -- we actually get static checking
    of our redeclarations, if #include is in the C code,
    or if the compiler knows the function.
    
    gcc does let us pass INTEGER to int w/o truncation warning,
    so do that. Ok?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20120912/c619f07b/attachment-0002.html>