Path: csiph.com!xmission!feeder.erje.net!2.eu.feeder.erje.net!feed.usenet.farm!feeder3.usenet.farm!aioe.org!.POSTED!not-for-mail From: Egor Newsgroups: comp.lang.c Subject: Re: C2 Aims to Modernize the C Language Date: Tue, 13 Feb 2018 13:14:25 +0200 Organization: Aioe.org NNTP Server Lines: 42 Message-ID: References: <20180211003235.f8b81e86a9275dd16af8eb40@gmail.com> <20180211044846.3164b7df534c8d6c3c127b49@gmail.com> <20180212000054.32bbfbfafa91930c5a09c41c@gmail.com> <20180212122916.ed1d64b3b64af5cd70bccb61@gmail.com> NNTP-Posting-Host: 9TfeVU2ewwpDwGvleIp7vA.user.gioia.aioe.org X-Complaints-To: abuse@aioe.org User-Agent: tin/2.4.1-20161224 ("Daill") (UNIX) (Linux/4.14.15-1-ARCH (x86_64)) X-Notice: Filtered by postfilter v. 0.8.3 Xref: csiph.com comp.lang.c:126651 bartc wrote: > On 12/02/2018 11:29, GOTHIER Nathan wrote: > You keep saying this. But you don't just call a label: > > call printf > > There are arguments to be passed, and values to be returned. That > information is documented in C terms. The mechanics might be stipulated > by the platform, but before that, you need to understand what the > parameters are. And that's where C gets in the way. I can only think of two ways in which C influences ABI design decisions: 1) null-terminated strings 2) caller-cleans for variadic functions. Having variadic callee-cleans functions is possible, but it's PITA to juggle the stack around before returning (Also it's easier to mess up the stack, if e.g. too many arguments are passed) Many ABI things are done a certain way because of the hardware, not because "it's defined like that in C". Take for example padding in structures: it's not there because of C, it's there because it's more efficient to access aligned words on most architectures, and some even throw exceptions at you if you access a word at an odd address (e.g. m68k). Another example: char being up-converted to int when passed to functions: you can only push words (and not bytes) on many arches including x86 and PDP-11 (which is what C was originally developed for) Clearly you don't need C to define the parameters of a function. The reason why C is usually chosen for documentation of function interface, is because C is the only low level language that's universally known, and is very portable. The major advantage of C over something like C2 is that it uses the "local convention" for types and ABI. By locking-in your FFI to certain types, you disregard every program which uses system ABI. Even if i32 is the usual way to pass integers to a function on *your* system, that doesn't mean that another system won't use i16 or i64 for that purpose. C doesn't do this, and so it doesn't have interoperability issues with other languages. In short, if it wasn't documented in C, it'd need to be documented separately for each platform.