Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Date: Sat, 24 Dec 2016 15:21:46 -0800 Organization: None to speak of Lines: 50 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="c83c5ff845c78dc2a3ff0094095b3024"; logging-data="16177"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Vcyn9E8S3HcVmurMaqj9D" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:1N6Ji+TbjFp5awqKxecuateP81s= sha1:a+ZvKBu32S1AMCIwDSPdrKEZjmg= Xref: csiph.com comp.lang.c:100203 BartC writes: [...] > So where exactly is the line drawn between your C code, the C library, > and the OS? It's C as far as you can see! Section 6 of the C standard defines the core language. Section 7 defines the standard C library. The OS is defined by whatever documentation accompanies it. Since the answer to your question is so simple and straightforward, I suspect I've missed your point. Could you clarify? Note that the Unix/POSIX I/O functions are things like open, close, read, and write. The C standard I/O function fopen, fclose, fread, fwrite et al are typically implemented on top of them (or on top of other primitives for non-POSIX systems). [...] > No just the simple part. At what point did it acquire all the stuff to > do with locales and wide characters? (Which doesn't even work: > atoi("456,789") just gives me 456. atoi() really ought to be > straightforward and not overambitious.) The standard says that atoi() is equivalent to strtol(), except for the lack of error checking. It doesn't say a whole lot about locales: In other than the "C" locale, additional locale-specific subject sequence forms may be accepted. and I've never looked into it. But atoi() is frankly a lousy little function that's in the standard only for historical reasons; it shouldn't be used except in toy programs. (It works fine if and only if you *know* that the argument string is valid.) I think you're saying that atoi() should be implemented along with the compiler rather than as part of a (possibly separately distributed) C library. What would be the advantage? Currently, as long as I have a working C implementation, I can write code that calls atoi() and expect it to work as specified; what more do you want? Do you think that the reorganization you propose would make it easier to set up a C implementation? Do you want the entire C standard library to be provided as part of the compiler package, or just the "simple" parts? -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"