<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><base href="x-msg://6827/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I don’t understand. Are you saying that the M3 declarations of these externals are wrong?<br>
<br><div><div>On Sep 8, 2012, at 5:54 AM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="hmmessage" style="font-size: 12pt; font-family: Calibri; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><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: <a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Date: Sat, 8 Sep 2012 09:50:19 +0000<br>Subject: [M3devel] C math interop..<br><br><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></div></blockquote></div><br></body></html>