Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: BGB Newsgroups: comp.lang.java.programmer Subject: Re: =?UTF-8?B?QW5kcm9pZOKAlFdoeSBEYWx2aWs/?= Date: Fri, 03 Jun 2011 12:17:43 -0700 Organization: albasani.net Lines: 51 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net 08OqUWBxG71DAkDfU1+FcYgBIAp07yEhPqfBhW5Yp0G62sMCl9Ik4D93uF5uStsBBP7GrqR4ArUrsGwRBXD0XQ== NNTP-Posting-Date: Fri, 3 Jun 2011 19:20:52 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="9OfY3ftH32mzlDR5UPJqXvb3pthzX3XL5qdzA+HbQ+qA53ciOE5YZc67CbMLSFu+A0Kxj5XCZJ84XeKL+Y47cr/RjuQEYNMkjmgaoPjvdbvHxg/O5H1KsV+Srz+z90tc"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 In-Reply-To: Cancel-Lock: sha1:FnxCK8yr/wsniZOS8q8oztqqCT4= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4947 On 6/3/2011 6:40 AM, Michael Wojcik wrote: > BGB wrote: >> >> yeah... sadly, the C ABI is a little bit prone to variations > > There is no "C ABI". If you believe otherwise, please cite the > appropriate language from ISO/IEC 9899. I'll accept any version. > more like "there is no universal standardized C ABI...", and nothing is stated in the C standards to this effect, but, there ARE C-ABIs... http://en.wikipedia.org/wiki/X86_calling_conventions note also: http://agner.org./optimize/calling_conventions.pdf much like there is a C++ ABI (or more correctly, many C++ ABIs...). but, the "standardized" (in a largely de-facto sense) ABI for C on 32-bit x86 is commonly known as cdecl, but it has other names. in its common form: arguments are passed right to left on the stack; structs are passed by passing an argument to the return location on the stack; generally, on non-ELF targets, all names have a prepended '_'; ... now, the issue is that not all compilers exactly agree on all the details, and these subtle differences can at times break code linked together from different compilers... these issues can also pop up sometimes when mixing a DLL compiled in one compiler with a main program compiled in another (such as using MinGW-compiled DLLs with a MSVC-compiled app, ...). granted, most of the time all this works without too much issue though, and careful handling can largely avoid many of these issues... example: use caution when passing/returning structs or SIMD types (preferably, don't directly pass SIMD types, such as "__m128", only structs containing floats or similar); don't use long-double in API calls; ...