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: Tue, 03 Jan 2017 16:22:09 -0800 Organization: None to speak of Lines: 53 Message-ID: References: <06544819-1f87-4e1c-94ca-918f049d1d42@googlegroups.com> <5bf5dcb7-ef8c-4d6b-aa1b-11f0522651b7@googlegroups.com> <4c08dfe0-afbf-4a76-862d-784ad66dc2d6@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="167f7d05f22907ea8e3985ed50c4ed73"; logging-data="9414"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+s9PGrGz9rXMLZxat907A3" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:1aXrpKLHj+ZmWhZGbp/TH9NTOcg= sha1:LxOBctj7rb7HzD3hyp983vp1A0E= Xref: csiph.com comp.lang.c:101062 supercat@casperkitty.com writes: > On Tuesday, January 3, 2017 at 4:28:44 PM UTC-6, Ian Collins wrote: >> On 01/ 4/17 11:07 AM, supercat wrote: >> > What in the Standard would exempt any implementation, even one for which >> > the underlying platform is annoying, from a guarantee that malloc() will >> > never do anything other than yield null or yield a usable pointer, with >> > no other side-effects? >> >> Nothing. Linux with over commit enabled isn't POSIX compliant. > > Fair point, though it would remain an example of a platform where compliance > would require forgoing some platform features that would in some cases be > more useful than Standard compliance. > > Returning to my earlier point, earlier point that many implementations are > designed to either be invoked with a command-line option which predefines > a macro which makes them non-compliant with the C Standard, or without that > option which would prevent them from running some POSIX code without > modification (it would be pointless to have C files use #define to enable > POSIX features rather than #include , but for whatever reason C > compilers almost always include command-line options to predefine macros but > seldom include command-line options to include the contents of a given file > before each C file, so pre-defining the macro that enables POSIX features > before including standard headers is equivalent to including a > file.) Dude, sentences! There is no header. POSIX-specific functions are declared in several different headers, some of them ISO C headers (like ), some of them POSIX-specific (like ). Because POSIX declares some non-ISO-C functions in ISO C standard headers, it's necessary to define a macro such as _POSIX_C_SOURCE (which supersedes the older _POSIX_SOURCE) or _XOPEN_SOURCE before including the relevant headers. (The details are a bit complicated.) It's perfectly reasonable to write something like: #define _POSIX_C_SOURCE some_value #include if you want to use the POSIX functions that are declared in . If you want to define the macro in some other way, that's fine too -- but other approaches have the drawback that some of the information required to compile the source file is not contained in the source file itself. -- 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"