<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>hm. The advantage of not having wrappers, is you can declare things that don't exist.<div>Maybe only on some platforms.</div><div>So I'll probably fix the declarations.</div><div>For scaleb/ldexp/sqrt too.</div><div>(similar to what I did for strcat/strcpy in Cstring.i3 -- no wrappers, to avoid OpenBSD link warning/error)</div><div><br></div><div>Later,</div><div> - Jay<br><br><div><div id="SkyDrivePlaceholder"></div><hr id="stopSpelling">From: jay.krell@cornell.edu<br>To: m3devel@elegosoft.com<br>Date: Sat, 8 Sep 2012 09:50:19 +0000<br>Subject: [M3devel] C math interop..<br><br>
<style><!--
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:12pt;font-family:Calibri;}
--></style>
<div dir="ltr"><div>This also occured in FPU.ic</div><div><br></div><div>Math.ic.c:217: error: conflicting types for ‘signgam’</div><div>/usr/include/architecture/i386/math.h:543: error: previous declaration of ‘signgam’ was here</div><div>Math.ic.c:298: warning: conflicting types for built-in function ‘cabs’</div><div>Math.ic.c:302: error: conflicting types for ‘frexp’</div><div>Math.ic.c:306: error: conflicting types for ‘ldexp’</div><div>Math.ic.c:310: error: conflicting types for ‘modf’</div><div>Math.ic.c:329: error: conflicting types for ‘jn’</div><div>Math.ic.c:339: error: conflicting types for ‘yn’</div><div><br></div><div><br></div><div>Generally int vs. INTEGER confusion.</div><div>To fix these errors, I'm going to provide C wrappers for these functions, and everything else in the file.</div><div><br></div><div><br></div><div>This hints at some new way to do interop, fast like the old way, but with static checking,</div><div>where the generated C #includes the relevant .h files.</div><div>But this is a bit abstraction bending -- the backend isn't supposed to be doing these checks.</div><div>The frontend does.</div><div>You'd have to have changes in the <* extern *> pragma like</div><div> - this isn't an actual function signature, necessarily..and the address can't</div><div>necessarily be taken, but something close enough to this will materialize from a C header</div><div> - specify the C header </div><div><br></div><div><br></div><div>Imagine a world with a good C backend, and a good other one.</div><div>Modules that interoperate with C could be sent off to the C backend automatically.</div><div><br></div><div><br></div><div>Anyway, just crazy stuff, nothing really happening here beyond I'll add C wrappers. :)</div><div><br></div><div><br></div><div>When I get to it, #include <Xlib.h> along with our declarations..it will be interesting</div><div>to see if things match. And <windows.h>...</div><div>There will be problems. We have one UINT32 type in the generated C.</div><div>Win32 has unsigned int and unsigned long used kind of interchangably.</div><div>There will be clashes.</div><div><br></div><div><br></div><div> - Jay</div> </div></div></div> </div></body>
</html>