f



How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code?

#include <stdio.h>
int main(void) {
   printf("%d\n",atoi("20161222"));
}


The current version of gcc is here.
http://mirrors.concertpass.com/gcc/releases/gcc-6.3.0/

Which file(s) in the compiler are responsible for converting 
atoi("20161222") into the final executable form?

Most gcc files are themselves .c and .h files.

I looked thru a bunch of files and other than a couple in the Go 
language folder, couldn't find a mention of atoi.

Thanks



0
DFS
12/23/2016 3:47:58 AM
comp.lang.c 30656 articles. 5 followers. spinoza1111 (3246) is leader. Post Follow

40 Replies
1069 Views

Similar Articles

[PageSpeed] 38

BartC <bc@freeuk.com> writes:
> On 23/12/2016 21:08, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> [...]
>>> Maybe you already knew enough to type in the right search terms. Doing
>>> something like "c atoi function source" didn't give anything useful on
>>> the first page.
>>
>> I just tried that exact search.  5 of the 10 results on the first page
>> included (attempted) implementations of atoi() -- most of them
>> incorrect.  Is that what you meant when you said the results weren't
>> useful?
>
> The first ten results were either about /using/ atoi, or various 
> assorted attempts to write a function like atoi, none of which seemed 
> likely to be an official implementation from a C library, or were more 
> generally about the C runtime library.

"Yes" would have been a perfectly good answer to my question.

What exactly do you mean by "official"?  Neither glibc nor any other
implementation has any official standing as far as the C standard is
concerned.  An implementation is conforming or not.

> The second page was more of the same. With a smattering of C++ versions.
>
> It's only when you start using "glibc atoi function source" that you get 
> more relevant results. So it's this "glibc" that appears to be the magic 
> keyword, that you have to know about.

glibc is *one* C library implementation.  Yes, it's GNU-specific.  If
you don't care about GNU-specific code, you don't need to know about it.

What exactly are you complaining about?

> What why should anyone know about "glibc"?

Why not?

Now you know about glibc.  You should now know what it is.  (And BTW if
you're using C on Windows, you're probably not using it glibc.)

What exactly are you complaining about?

>                                            It doesn't appear in K&R or 
> the C Standard.

Of course not.  Did you expect it to?

>                 It's also gnu-specific, but there must be plenty of 
> other C libraries (and people here are fond of pointing out that there 
> is no connection with a C compiler and a particular library. Apparently 
> they all interoperable.).

Some of them are interoperable.  Some are not.  There is no
requirement for a given library implementation to work with any
given compiler.  If a compiler and library work together correctly,
they can be the basis of a conforming C implementation.  If not,
they can't.

Come on, you know this stuff, don't you?

> I don't know however what search terms Ben used; or which search engine 
> (I used google).

Perhaps if you could clarify just what you're looking for, we could help
you find it.

If you're looking for a definitive implementation of atoi(), there's no
such thing.  If you're looking for one particular implementation, that's
going to depend on which one you want.  In some cases, the source won't
be available.

It might also help to know *why* you want the source code for atoi().
You certainly don't need that to be able to use it (which is why
implementers don't generally don't go out of their way to make it
easy to find).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"
0
Keith
12/23/2016 1:01:01 AM
On 2016-12-23, DFS <nospam@dfs.com> wrote:
> #include <stdio.h>
> int main(void) {
>    printf("%d\n",atoi("20161222"));
> }
>
>
> The current version of gcc is here.
> http://mirrors.concertpass.com/gcc/releases/gcc-6.3.0/
>
> Which file(s) in the compiler are responsible for converting 
> atoi("20161222") into the final executable form?
>
> Most gcc files are themselves .c and .h files.
>
> I looked thru a bunch of files and other than a couple in the Go 
> language folder, couldn't find a mention of atoi.

The atoi function is not part of gcc,
it's part of the C runtime library (glibc, if you use GNU).
0
Ike
12/23/2016 6:56:40 AM
On 23/12/16 03:47, DFS wrote:
> #include <stdio.h>
> int main(void) {
>   printf("%d\n",atoi("20161222"));
> }

Ike Naar has answered your question, so I'll just add some diagnostics:

1) you have no declaration in scope for atoi. You should add:

#include <stdlib.h>

2) you fall off the end of main without returning a value. This is 
explicitly given a meaning in C99 and later (main returns 0), but in C90 
it means the return status is undefined.

3) INT_MAX is not required to exceed 32767; if it is lower than 
20161222, the behaviour of your program is undefined. Your documentation 
will tell you what INT_MAX is for your implementation. Alternatively, 
you can run the following program:

#include <stdio.h>
#include <limits.h>

int main(void)
{
   printf("INT_MAX = %d\n", INT_MAX);
   return 0;
}

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
0
Richard
12/23/2016 9:52:13 AM
On 23/12/2016 06:56, Ike Naar wrote:
> On 2016-12-23, DFS <nospam@dfs.com> wrote:
>> #include <stdio.h>
>> int main(void) {
>>    printf("%d\n",atoi("20161222"));
>> }
>>
>>
>> The current version of gcc is here.
>> http://mirrors.concertpass.com/gcc/releases/gcc-6.3.0/
>>
>> Which file(s) in the compiler are responsible for converting
>> atoi("20161222") into the final executable form?
>>
>> Most gcc files are themselves .c and .h files.
>>
>> I looked thru a bunch of files and other than a couple in the Go
>> language folder, couldn't find a mention of atoi.
>
> The atoi function is not part of gcc,
> it's part of the C runtime library (glibc, if you use GNU).
>

I've got a directory which appears to be the source code for gcc, or a 
version of it.

Do you mean that, despite the 52,000 .c and .h files, it still doesn't 
include sources for the C libraries?

I think it would be quicker to just write an atoi() function rather than 
try and find the source online!

-- 
Bartc


0
BartC
12/23/2016 11:08:25 AM
On 23/12/2016 03:47, DFS wrote:
> #include <stdio.h>
> int main(void) {
>   printf("%d\n",atoi("20161222"));
> }
>
>
> The current version of gcc is here.
> http://mirrors.concertpass.com/gcc/releases/gcc-6.3.0/
>
> Which file(s) in the compiler are responsible for converting
> atoi("20161222") into the final executable form?

atoi() probably already exists in a binary form inside a library (in any 
of .a, .o, .obj. .lib, .dll, .so files for example).

So it will have been translated at some point, but not when you compile 
your program.

-- 
Bartc
0
BartC
12/23/2016 11:16:40 AM
On 23/12/16 11:08, BartC wrote:
> On 23/12/2016 06:56, Ike Naar wrote:

<snip>

>> The atoi function is not part of gcc,
>> it's part of the C runtime library (glibc, if you use GNU).
>>
>
> I've got a directory which appears to be the source code for gcc, or a
> version of it.
>
> Do you mean that, despite the 52,000 .c and .h files, it still doesn't
> include sources for the C libraries?

Yes, he means that the source code for one program doesn't appear within 
the source code for another program. So what? Do you include all the 
source for all your programs within all your other programs?

> I think it would be quicker to just write an atoi() function rather than
> try and find the source online!

Why do you think he wants to find the source for atoi? I can think of 
three possible reasons:

1. He wants to study the source in an attempt to learn how one might go 
about writing an atoi function, in which case the advice to "write your 
own", despite having a certain merit, is likely to make him throw up his 
hands in frustration at your intransigence;

2. he wants to study the source in order to see precisely how the 
specific implementation handles the task of converting a string 
representation of a number into the number itself, in which case "write 
your own" completely misses the point;

3. he wants to modify the source in some way (perhaps to add an error 
detection mechanism), in which case "write your own", while again being 
perhaps a better solution, is again more likely to frustrate him than to 
educate him.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
0
Richard
12/23/2016 11:26:52 AM
On 23/12/2016 11:26, Richard Heathfield wrote:
> On 23/12/16 11:08, BartC wrote:
>> On 23/12/2016 06:56, Ike Naar wrote:
>
> <snip>
>
>>> The atoi function is not part of gcc,
>>> it's part of the C runtime library (glibc, if you use GNU).
>>>
>>
>> I've got a directory which appears to be the source code for gcc, or a
>> version of it.
>>
>> Do you mean that, despite the 52,000 .c and .h files, it still doesn't
>> include sources for the C libraries?
>
> Yes, he means that the source code for one program doesn't appear within
> the source code for another program. So what? Do you include all the
> source for all your programs within all your other programs?

If my program was a language implementation and this was a part of the 
standard library for the language, then yes I would (and have done).

I wouldn't if such a function was clearly part of an external library or 
part of the OS.

In this case, atoi() is mentioned in the C standard, it's declared in 
the standard headers (stdlib.h) and it's mentioned in multiple places in 
K&R.

I don't know what else is needed to show that atoi() is an integral part 
of the language.

> I think it would be quicker to just write an atoi() function rather than
>> try and find the source online!
>
> Why do you think he wants to find the source for atoi?

Actually there is an implementation of it on page 43 of K&R2. All 8 
lines of it.

You'd think gcc would have a bundled /a/ version of the standard 
libraries just to get started with. And the standard headers because 
apparently these are not part of a C compiler either! It wouldn't make a 
dent in the size of the distribution (some 0.6GB).

Otherwise you'd go to all the trouble of building this massive great 
compiler and not being able to compile the Hello, World example on page 
6 of K&R2.

(Well, unless you made use of the C implementation you needed to build 
gcc. But you might take the newly-created gcc executables, and ship them 
to someone else who's got a copy of K&R and keen to get started on the 
exercises. And who's going to be disappointed.)

-- 
Bartc
0
BartC
12/23/2016 12:09:26 PM
BartC <bc@freeuk.com> writes:
<snip>

> I think it would be quicker to just write an atoi() function rather
> than try and find the source online!

I'm a pretty fast coder but since I found it in about 20 seconds I don't
think that I could.  Mind you, it turns out to be one line (a call to
strtol) so maybe I could have.  That's not the sort of implementation
you were talking about though.

-- 
Ben.
0
Ben
12/23/2016 12:33:38 PM
On 23/12/16 12:09, BartC wrote:
> On 23/12/2016 11:26, Richard Heathfield wrote:
>> On 23/12/16 11:08, BartC wrote:
>>> On 23/12/2016 06:56, Ike Naar wrote:
>>
>> <snip>
>>
>>>> The atoi function is not part of gcc,
>>>> it's part of the C runtime library (glibc, if you use GNU).
>>>>
>>>
>>> I've got a directory which appears to be the source code for gcc, or a
>>> version of it.
>>>
>>> Do you mean that, despite the 52,000 .c and .h files, it still doesn't
>>> include sources for the C libraries?
>>
>> Yes, he means that the source code for one program doesn't appear within
>> the source code for another program. So what? Do you include all the
>> source for all your programs within all your other programs?
>
> If my program was a language implementation and this was a part of the
> standard library for the language, then yes I would (and have done).

I don't think you mean what you're saying here. You are saying "yes" to 
the question "do you include all the source for all your programs within 
all your other programs?" but I think you mean you consider the language 
implementation and the library implementation to be one and the same. 
Fine, that's a perfectly valid point of view, but not the /only/ valid 
point of view. The GNU folks have a different take on it, and consider 
the language implementation and the library implementation to be 
separate projects.

> I wouldn't if such a function was clearly part of an external library or
> part of the OS.

The GNU people consider the standard library to be an external library 
(or, rather, two external libraries!).

> In this case, atoi() is mentioned in the C standard, it's declared in
> the standard headers (stdlib.h) and it's mentioned in multiple places in
> K&R.

Indeed. It is, in fact, part of the standard library, which in the GNU 
implementation is separate from the compiler etc.

> I don't know what else is needed to show that atoi() is an integral part
> of the language.

Of course it is (although, arguably, it shouldn't be). But the C 
Standard only requires that the function must be available for hosted 
implementations --- it doesn't say in what way it must be made available.

>> I think it would be quicker to just write an atoi() function rather than
>>> try and find the source online!
>>
>> Why do you think he wants to find the source for atoi?
>
> Actually there is an implementation of it on page 43 of K&R2. All 8
> lines of it.

Have you tested it? It doesn't work very well.

> You'd think gcc would have a bundled /a/ version of the standard
> libraries just to get started with.

If you want the GNU people to change their policy, I suggest you contact 
them directly. This newsgroup can't change their minds for you. In the 
meantime, if you ask your OS to install gcc for you, it will typically 
install glibc as well, so it really isn't a problem for anyone except you.

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
0
Richard
12/23/2016 12:34:41 PM
BartC <bc@freeuk.com> writes:

> If my program was a language implementation and this was a part of the
> standard library for the language, then yes I would (and have done).

Well, gcc is part of a wider project which has an implementation of the
standard C library (and more, it targets even more than the whole Posix
library) as another subproject.  That they bundle those two projects
together or not is just a matter of organization.

Considering that one of their target is Unix system which have a standard C
library tightly coupled with their system library (in fact the standard C
library started as part of the system independent part of that library,
with explain some misdesigns like strncpy which was not aiming to be a
general purpose string manipulation function), it makes sense to separate
both.

I think they dropped the goal for their library implementation to be usable
on other systems than Linux some time ago but I've used it on SunOS or on
Solaris at the time when the Sun provided library was not POSIX enough for
my purpose, with the Sun compiler.  So that separation make even more sense
at the time.

One of the place where gcc is used is in embedded world, it makes even more
sense to separate both.  So much that there is at least one other standard
C library designed for the embedded world (it's not part of the GNU
project, but it is provided by a company who is working on GCC).

And BTW gcc provides and has always provided the part of the standard C
library which are more tighlty coupled with the compiler.

And GCC provides the standard library for other languages bundled with the
compiler.  So it is not that they are really adverse to providing the
library part.  It really looks like the choice was driven by consideration
about their users convenience.

Yours,

-- 
Jean-Marc
0
Jean
12/23/2016 12:36:10 PM
On Friday, December 23, 2016 at 3:48:17 AM UTC, DFS wrote:
> #include <stdio.h>
> int main(void) {
>    printf("%d\n",atoi("20161222"));
> }
> 
> 
> The current version of gcc is here.
> http://mirrors.concertpass.com/gcc/releases/gcc-6.3.0/
> 
> Which file(s) in the compiler are responsible for converting 
> atoi("20161222") into the final executable form?
> 
> Most gcc files are themselves .c and .h files.
> 
> I looked thru a bunch of files and other than a couple in the Go 
> language folder, couldn't find a mention of atoi.
> 
It;s virtually impossible to reverse engineer a huge hunk of
software like gcc like that. If you root around in the documentation
for developers it will tell you where the code for compiling atoi 
is stored. It's probably inlined as a special function because
it is standard and so simple.
0
Malcolm
12/23/2016 12:36:55 PM
BartC <bc@freeuk.com> writes:

> On 23/12/2016 11:26, Richard Heathfield wrote:
>> On 23/12/16 11:08, BartC wrote:
>>> On 23/12/2016 06:56, Ike Naar wrote:
>>
>> <snip>
>>
>>>> The atoi function is not part of gcc,
>>>> it's part of the C runtime library (glibc, if you use GNU).
>>>>
>>>
>>> I've got a directory which appears to be the source code for gcc, or a
>>> version of it.
>>>
>>> Do you mean that, despite the 52,000 .c and .h files, it still doesn't
>>> include sources for the C libraries?
>>
>> Yes, he means that the source code for one program doesn't appear within
>> the source code for another program. So what? Do you include all the
>> source for all your programs within all your other programs?
>
> If my program was a language implementation and this was a part of the
> standard library for the language, then yes I would (and have done).

But if your compiler were meant to be able to use the host's native C
runtime (even if only as a option) you would be wise to keep them
separate.

> I wouldn't if such a function was clearly part of an external library
> or part of the OS.
>
> In this case, atoi() is mentioned in the C standard, it's declared in
> the standard headers (stdlib.h) and it's mentioned in multiple places
> in K&R.
>
> I don't know what else is needed to show that atoi() is an integral
> part of the language.

You don't need anything else.  It is part of the language in every sense
that matters.  The bit you are missing is that some programmers like to
to be able to choose the details of the language implementation so C
compilers rarely force you to use one and only one C library.

<snip>
-- 
Ben.
0
Ben
12/23/2016 12:39:31 PM
DFS <nospam@dfs.com> writes:

> #include <stdio.h>
> int main(void) {
>   printf("%d\n",atoi("20161222"));
> }
>
>
> The current version of gcc is here.
> http://mirrors.concertpass.com/gcc/releases/gcc-6.3.0/
>
> Which file(s) in the compiler are responsible for converting
> atoi("20161222") into the final executable form?

No one has answered the question you asked though it's possible you
meant the questions that was answered.

gcc will treat atoi("20161222") as a normal function call but you won't
be able to find the files that do that.  The process involves many
stages so there is no one place where the expression atoi("20161222") is
converted.  In fact, many program will be involved.  The compiler's
output will be assembled into what is called an object file, and that
will be linked with a C library to generate the final executable form.

> Most gcc files are themselves .c and .h files.
>
> I looked thru a bunch of files and other than a couple in the Go
> language folder, couldn't find a mention of atoi.

This suggests that you are asking about the internals of atoi.  It's
good to explore sources, but always remember that they are the result of
decades of development and are often far more complex than one might
expect.

Here is glibc's atoi:

  http://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/atoi.c

as you can see it is just a call to the main string to number conversion
function which is here.  When you go looking for that you will find a
lot of internal gcc housekeeping code that eventually leads you to 

  http://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/strtol_l.c

but there is a lot of noise in that file too.  The implementation
includes extensions and various other complications that make it very
hard to see what's really going on.

-- 
Ben.
0
Ben
12/23/2016 1:01:42 PM
Richard Heathfield <rjh@cpax.org.uk> writes:
>Why do you think he wants to find the source for atoi? I can think of 
>three possible reasons:

  Some participants of my courses ask for the library source
  code until they understand that all the information they
  need is contained in the library documentation.

  But still, one can be curious how something is implemented,
  and it is not always easy to find the library sources.

  Some callable entities are realized by macros in the header
  files one already has somewhere on the local file system.

  To find atoi sources with a search engine:

"This file is part of the GNU C Library" "atoi"

  or

inurl:atoi.c

  .

0
ram
12/23/2016 1:34:30 PM
On 23/12/2016 12:33, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
> <snip>
>
>> I think it would be quicker to just write an atoi() function rather
>> than try and find the source online!
>
> I'm a pretty fast coder but since I found it in about 20 seconds I don't
> think that I could.

Maybe you already knew enough to type in the right search terms. Doing 
something like "c atoi function source" didn't give anything useful on 
the first page.

-- 
Bartc

0
BartC
12/23/2016 5:21:23 PM
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
> If you want the GNU people to change their policy, I suggest you contact 
> them directly. This newsgroup can't change their minds for you. In the 
> meantime, if you ask your OS to install gcc for you, it will typically 
> install glibc as well, so it really isn't a problem for anyone except you.

That depends on the OS.

Most Linux distributions come with gcc and glibc preinstalled.  As new
versions become available, they can generally be updated independently.

MacOS uses a different library implementation; I don't know whether
you can install glibc or not.  It also has transitioned from gcc
to clang by default, but you can still install gcc.  And both gcc
and clang use the same library implementation.

And Windows doesn't have a way to "ask your OS" to install gcc; you
have to find a third-party installation package, which is likely to
include both a compiler and a library (probably not glibc).  (Yes,
installing a working non-Microsoft C implementation on Windows is
more difficult than it should be.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"
0
Keith
12/23/2016 8:56:52 PM
On 23/12/16 20:56, Keith Thompson wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
> [...]
>> If you want the GNU people to change their policy, I suggest you contact
>> them directly. This newsgroup can't change their minds for you. In the
>> meantime, if you ask your OS to install gcc for you, it will typically
>> install glibc as well, so it really isn't a problem for anyone except you.
>
> That depends on the OS.
>
> Most Linux distributions come with gcc and glibc preinstalled.  As new
> versions become available, they can generally be updated independently.

Yes, that's right.

> MacOS uses a different library implementation; I don't know whether
> you can install glibc or not.  It also has transitioned from gcc
> to clang by default, but you can still install gcc.  And both gcc
> and clang use the same library implementation.

I don't actually have a Mac, so I'll have to take your word for it.

> And Windows doesn't have a way to "ask your OS" to install gcc;

I'm sorry --- I thought I said "OS", not "shop window". :-)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
0
Richard
12/23/2016 8:58:24 PM
BartC <bc@freeuk.com> writes:
[...]
> Maybe you already knew enough to type in the right search terms. Doing 
> something like "c atoi function source" didn't give anything useful on 
> the first page.

I just tried that exact search.  5 of the 10 results on the first page
included (attempted) implementations of atoi() -- most of them
incorrect.  Is that what you meant when you said the results weren't
useful?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"
0
Keith
12/23/2016 9:08:48 PM
On 23/12/16 20:56, Keith Thompson wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
> [...]
>> If you want the GNU people to change their policy, I suggest you contact
>> them directly. This newsgroup can't change their minds for you. In the
>> meantime, if you ask your OS to install gcc for you, it will typically
>> install glibc as well, so it really isn't a problem for anyone except you.
>
> That depends on the OS.

Actually, I should explain why I worded it like that. (I take your point 
about the details, of course.)

What I meant was that, if you go poking around for the gcc source and 
begin a world of pain with configure, make, etc, then obviously you're 
/not/ going to get glibc as part of that process. The distinction I was 
trying to draw was that between automated install and manual install.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
0
Richard
12/23/2016 9:09:48 PM
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> It;s virtually impossible to reverse engineer a huge hunk of
> software like gcc like that. If you root around in the documentation
> for developers it will tell you where the code for compiling atoi 
> is stored. It's probably inlined as a special function because
> it is standard and so simple.

A quick experiment shows that gcc generates a call to strtol() when
optimization is enabled.  I haven't taken the time to figure out how
it does that, whether it knows that atoi() is a standard function,
or whether it takes advantage of some annotation on the declaration.

It should also be mentioned that atoi() is a poorly designed
function.  It performs no error checking.  atoi("FOO") is likely
to return 0, but the behavior is undefined.  All the standard says
is that

    Except for the behavior on error, [atoi is] equivalent to
        (int)strtol(nptr, (char **)NULL, 10)

Certainly if strtol returns a result that's outside the range of int,
the cast has undefined behavior.  If there's an error, the standard
doesn't say anything about how atoi behaves, which means the behavior
is undefined.  (I'd be happier if it said so explicitly.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"
0
Keith
12/23/2016 9:24:47 PM
On 23/12/2016 21:08, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
> [...]
>> Maybe you already knew enough to type in the right search terms. Doing
>> something like "c atoi function source" didn't give anything useful on
>> the first page.
>
> I just tried that exact search.  5 of the 10 results on the first page
> included (attempted) implementations of atoi() -- most of them
> incorrect.  Is that what you meant when you said the results weren't
> useful?

The first ten results were either about /using/ atoi, or various 
assorted attempts to write a function like atoi, none of which seemed 
likely to be an official implementation from a C library, or were more 
generally about the C runtime library.

The second page was more of the same. With a smattering of C++ versions.

It's only when you start using "glibc atoi function source" that you get 
more relevant results. So it's this "glibc" that appears to be the magic 
keyword, that you have to know about.

What why should anyone know about "glibc"? It doesn't appear in K&R or 
the C Standard. It's also gnu-specific, but there must be plenty of 
other C libraries (and people here are fond of pointing out that there 
is no connection with a C compiler and a particular library. Apparently 
they all interoperable.).

I don't know however what search terms Ben used; or which search engine 
(I used google).

-- 
Bartc
0
BartC
12/23/2016 10:33:40 PM
On Friday, December 23, 2016 at 10:33:53 PM UTC, Bart wrote:
>
> What why should anyone know about "glibc"? It doesn't appear in K&R or 
> the C Standard. It's also gnu-specific, but there must be plenty of 
> other C libraries (and people here are fond of pointing out that there 
> is no connection with a C compiler and a particular library. Apparently 
> they all interoperable.).
> 
> I don't know however what search terms Ben used; or which search engine 
> (I used google).
> 
If I remember rightly, glibc is a monster of a thing that includes
the C standard library then a whole host of threading, sockets, file
system and other operating system type stuff as well.

I don't know if you can prevent gcc from linking to it. If you did,
the question would be how to get any output from the program at all. 

0
Malcolm
12/23/2016 10:55:36 PM
On 23/12/2016 23:12, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> On 23/12/2016 21:08, Keith Thompson wrote:
>>> BartC <bc@freeuk.com> writes:
>>> [...]
>>>> Maybe you already knew enough to type in the right search terms. Doing
>>>> something like "c atoi function source" didn't give anything useful on
>>>> the first page.
>>>
>>> I just tried that exact search.  5 of the 10 results on the first page
>>> included (attempted) implementations of atoi() -- most of them
>>> incorrect.  Is that what you meant when you said the results weren't
>>> useful?
>>
>> The first ten results were either about /using/ atoi, or various
>> assorted attempts to write a function like atoi, none of which seemed
>> likely to be an official implementation from a C library, or were more
>> generally about the C runtime library.
>
> "Yes" would have been a perfectly good answer to my question.
>
> What exactly do you mean by "official"?  Neither glibc nor any other
> implementation has any official standing as far as the C standard is
> concerned.  An implementation is conforming or not.
>
>> The second page was more of the same. With a smattering of C++ versions.
>>
>> It's only when you start using "glibc atoi function source" that you get
>> more relevant results. So it's this "glibc" that appears to be the magic
>> keyword, that you have to know about.
>
> glibc is *one* C library implementation.  Yes, it's GNU-specific.  If
> you don't care about GNU-specific code, you don't need to know about it.
>
> What exactly are you complaining about?
>
>> What why should anyone know about "glibc"?
>
> Why not?
>
> Now you know about glibc.  You should now know what it is.  (And BTW if
> you're using C on Windows, you're probably not using it glibc.)
>
> What exactly are you complaining about?
>
>>                                            It doesn't appear in K&R or
>> the C Standard.
>
> Of course not.  Did you expect it to?
>
>>                 It's also gnu-specific, but there must be plenty of
>> other C libraries (and people here are fond of pointing out that there
>> is no connection with a C compiler and a particular library. Apparently
>> they all interoperable.).
>
> Some of them are interoperable.  Some are not.  There is no
> requirement for a given library implementation to work with any
> given compiler.  If a compiler and library work together correctly,
> they can be the basis of a conforming C implementation.  If not,
> they can't.
>
> Come on, you know this stuff, don't you?
>
>> I don't know however what search terms Ben used; or which search engine
>> (I used google).
>
> Perhaps if you could clarify just what you're looking for, we could help
> you find it.
>
> If you're looking for a definitive implementation of atoi(), there's no
> such thing.  If you're looking for one particular implementation, that's
> going to depend on which one you want.  In some cases, the source won't
> be available.
>
> It might also help to know *why* you want the source code for atoi().
> You certainly don't need that to be able to use it (which is why
> implementers don't generally don't go out of their way to make it
> easy to find).

I'm not sure about the point of your post. /I'm/ not looking for the 
atoi source; the OP is. I think.

I remarked that finding an atoi implementation from an actual library 
seemed elusive enough to make it easier to just write one. Ben said he 
managed it in 20 seconds. I then suggested he might have been using his 
expert knowledge to more easily pin point the source which is why it 
only took 20 seconds.

Point made and end of story.

What do I have to be constantly on the defensive?

-- 
Bartc



0
BartC
12/24/2016 1:08:48 AM
On 12/24/16 01:09 AM, BartC wrote:
> On 23/12/2016 11:26, Richard Heathfield wrote:
>> On 23/12/16 11:08, BartC wrote:
>>> On 23/12/2016 06:56, Ike Naar wrote:
>>
>> <snip>
>>
>>>> The atoi function is not part of gcc,
>>>> it's part of the C runtime library (glibc, if you use GNU).
>>>>
>>>
>>> I've got a directory which appears to be the source code for gcc, or a
>>> version of it.
>>>
>>> Do you mean that, despite the 52,000 .c and .h files, it still doesn't
>>> include sources for the C libraries?
>>
>> Yes, he means that the source code for one program doesn't appear within
>> the source code for another program. So what? Do you include all the
>> source for all your programs within all your other programs?
>
> If my program was a language implementation and this was a part of the
> standard library for the language, then yes I would (and have done).
>
> I wouldn't if such a function was clearly part of an external library or
> part of the OS.
>
> In this case, atoi() is mentioned in the C standard, it's declared in
> the standard headers (stdlib.h) and it's mentioned in multiple places in
> K&R.
>
> I don't know what else is needed to show that atoi() is an integral part
> of the language.

Unix systems have always had their own standard library implementations.

Who is better qualified to write the code that interfaces with and must 
be aware of the behaviour of the OS, the OS writers, or compiler writers?

-- 
Ian
0
Ian
12/24/2016 3:46:38 AM
BartC <bc@freeuk.com> writes:

<snip>
> I remarked that finding an atoi implementation from an actual library
> seemed elusive enough to make it easier to just write one. Ben said he
> managed it in 20 seconds. I then suggested he might have been using
> his expert knowledge to more easily pin point the source which is why
> it only took 20 seconds.

I searched for gnu atoi source, IIRC.  Is that using expert knowledge?

<snip>
-- 
Ben.
0
Ben
12/24/2016 4:12:50 AM
On 24/12/2016 02:08, BartC wrote:

> [Why] do I have to be constantly on the defensive?

Because, whether you realize it (which would make you an effective troll)
or not (which would make you a royal PITA) your unwillingness to learn
anything about "formal" C, and your eagerness to flaunt the supposed or
imagined benefits of your C-like languages over C (in a C newsgroup
nonetheless), do have a tendency to drive some participants up the wall.

0
Noob
12/24/2016 10:34:32 AM
On 24/12/2016 10:34, Noob wrote:
> On 24/12/2016 02:08, BartC wrote:
>
>> [Why] do I have to be constantly on the defensive?
>
> Because, whether you realize it (which would make you an effective troll)
> or not (which would make you a royal PITA) your unwillingness to learn
> anything about "formal" C, and your eagerness to flaunt the supposed or
> imagined benefits of your C-like languages over C (in a C newsgroup
> nonetheless), do have a tendency to drive some participants up the wall.

I remember attempting to learn French numbers a few years ago and was 
surprised at how weird they got from 80 onwards (so 86 is 4-twenties and 
6, and 93 is 4-twenties and thirteen).

Yet Swiss-French apparently uses 8-tens and 6, and 9-tens and 3, just 
like we do. If I was a Swiss living in France I don't think I'd be able 
to resist showing the natives how to count properly! Rather than having 
to count their way.

Anyway next year I might have a go at doing a C compiler, then I can 
bore everyone showing them how /that/ should be done!


(But why wait? Here are some early thoughts:
https://github.com/bartg/langs/blob/master/ccp.md)


-- 
Bartc



0
BartC
12/24/2016 12:47:30 PM
On 24/12/2016 03:46, Ian Collins wrote:
> On 12/24/16 01:09 AM, BartC wrote:

>> I don't know what else is needed to show that atoi() is an integral part
>> of the language.
>
> Unix systems have always had their own standard library implementations.

Of what? The C library?

If so, do they have standard library implementations for Cobol, Lisp and 
K too? Do they have matrix-multiplication routines for maths languages?

I think there is too much cosiness between C and Unix, such that you 
can't tell what is part of the language and what is part of the OS. That 
can make things confusing.

> Who is better qualified to write the code that interfaces with and must
> be aware of the behaviour of the OS, the OS writers, or compiler writers?

In the case of a simple version of atoi(), you would expect this to be 
part of a library specific to a language.

(Anyone wanting to understand how this stuff works would be better off I 
think looking at Windows rather than Unix. Then the demarcations become 
clearer. fopen() doesn't exist in the Windows API and presumably has to 
be implemented on top of OpenFile.)

-- 
Bartc
0
BartC
12/24/2016 1:04:46 PM
In article <o3lqmg$pn5$1@dont-email.me>, BartC  <bc@freeuk.com> wrote:
....
>Anyway next year I might have a go at doing a C compiler, then I can 
>bore everyone showing them how /that/ should be done!
>
>
>(But why wait? Here are some early thoughts:
>https://github.com/bartg/langs/blob/master/ccp.md)
                        ^

c or g?

-- 

First of all, I do not appreciate your playing stupid here at all.

	- Thomas 'PointedEars' Lahn -
0
gazelle
12/24/2016 1:13:11 PM
On 24/12/2016 13:13, Kenny McCormack wrote:
> In article <o3lqmg$pn5$1@dont-email.me>, BartC  <bc@freeuk.com> wrote:
> ...
>> Anyway next year I might have a go at doing a C compiler, then I can
>> bore everyone showing them how /that/ should be done!
>>
>>
>> (But why wait? Here are some early thoughts:
>> https://github.com/bartg/...
>
> c or g?

g. Maybe bartc was taken and the g signifies github. I can't remember.

But the link should work.

-- 
bartc

0
BartC
12/24/2016 2:02:50 PM
On 24/12/2016 04:12, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
> <snip>
>> I remarked that finding an atoi implementation from an actual library
>> seemed elusive enough to make it easier to just write one. Ben said he
>> managed it in 20 seconds. I then suggested he might have been using
>> his expert knowledge to more easily pin point the source which is why
>> it only took 20 seconds.
>
> I searched for gnu atoi source, IIRC.  Is that using expert knowledge?

The gnu part, yes.



0
BartC
12/24/2016 3:12:12 PM
BartC <bc@freeuk.com> writes:
> On 24/12/2016 10:34, Noob wrote:
>> On 24/12/2016 02:08, BartC wrote:
>>> [Why] do I have to be constantly on the defensive?
>>
>> Because, whether you realize it (which would make you an effective troll)
>> or not (which would make you a royal PITA) your unwillingness to learn
>> anything about "formal" C, and your eagerness to flaunt the supposed or
>> imagined benefits of your C-like languages over C (in a C newsgroup
>> nonetheless), do have a tendency to drive some participants up the wall.
>
> I remember attempting to learn French numbers a few years ago and was 
> surprised at how weird they got from 80 onwards (so 86 is 4-twenties and 
> 6, and 93 is 4-twenties and thirteen).
>
> Yet Swiss-French apparently uses 8-tens and 6, and 9-tens and 3, just 
> like we do. If I was a Swiss living in France I don't think I'd be able 
> to resist showing the natives how to count properly! Rather than having 
> to count their way.

And it would be interesting to see how that would work out.

I suspect you'd spend a great deal of time explaining to the French
that their numbering system is inefficient, and the Swiss-French
version is much more logical -- *as if they weren't already perfectly
aware of that*.

Just like you explain to us that C has problems that we already know
about, and ignore any attempts to explain the historical basis for
those problems and ways to work with the language in spite of them.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"
0
Keith
12/24/2016 8:36:49 PM
On 12/25/16 02:04 AM, BartC wrote:
> On 24/12/2016 03:46, Ian Collins wrote:
>> On 12/24/16 01:09 AM, BartC wrote:
>
>>> I don't know what else is needed to show that atoi() is an integral part
>>> of the language.
>>
>> Unix systems have always had their own standard library implementations.
>
> Of what? The C library?

Isn't that what I wrote?

> If so, do they have standard library implementations for Cobol, Lisp and
> K too? Do they have matrix-multiplication routines for maths languages?

Why should they?  C is the interface language for the OS.

> I think there is too much cosiness between C and Unix, such that you
> can't tell what is part of the language and what is part of the OS. That
> can make things confusing.

Not really, the two grew up together and that's the way it has always 
been.  You have to have an interface between the OS and user code and 
the C standard library forms part of the interface.  Choosing to write 
your own interface and then implement a C library on top of that is a 
pointless duplication of work.

>> Who is better qualified to write the code that interfaces with and must
>> be aware of the behaviour of the OS, the OS writers, or compiler writers?
>
> In the case of a simple version of atoi(), you would expect this to be
> part of a library specific to a language.

atoi() is part of the standard library, are you advocating breaking it 
up into simple bits and harder bits?  Where would you draw the line?

-- 
Ian
0
Ian
12/24/2016 8:43:06 PM
On Saturday, December 24, 2016 at 8:37:00 PM UTC, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
> 
> > Yet Swiss-French apparently uses 8-tens and 6, and 9-tens and 3, just 
> > like we do. If I was a Swiss living in France I don't think I'd be able 
> > to resist showing the natives how to count properly! Rather than having 
> > to count their way.
> 
> And it would be interesting to see how that would work out.
> 
> I suspect you'd spend a great deal of time explaining to the French
> that their numbering system is inefficient, and the Swiss-French
> version is much more logical -- *as if they weren't already perfectly
> aware of that*.
> 
> Just like you explain to us that C has problems that we already know
> about, and ignore any attempts to explain the historical basis for
> those problems and ways to work with the language in spite of them.
> 
Just as in English we used to say "five score and ten", or "two dozen".
You'll still occasionally hear the latter, but the first is now pretty
archaic. In French they've kept "fourscore" in general use.
0
Malcolm
12/24/2016 9:59:14 PM
On 24/12/2016 20:43, Ian Collins wrote:
> On 12/25/16 02:04 AM, BartC wrote:
>> On 24/12/2016 03:46, Ian Collins wrote:
>>> On 12/24/16 01:09 AM, BartC wrote:
>>
>>>> I don't know what else is needed to show that atoi() is an integral
>>>> part
>>>> of the language.
>>>
>>> Unix systems have always had their own standard library implementations.
>>
>> Of what? The C library?
>
> Isn't that what I wrote?
>
>> If so, do they have standard library implementations for Cobol, Lisp and
>> K too? Do they have matrix-multiplication routines for maths languages?
>
> Why should they?  C is the interface language for the OS.

It's the interface language for Windows too (or Win16 and early Win32; 
now they call the same interface a C++ one).

But there the API is clearly not the C library. Win API functions must 
be accessed via cross-language and cross-compiler DLL files; you can't 
choose to statically link them into your program.

It's clear what is part of the language and what isn't. And that the Win 
API won't work under Unix.

>> I think there is too much cosiness between C and Unix, such that you
>> can't tell what is part of the language and what is part of the OS. That
>> can make things confusing.
>
> Not really, the two grew up together and that's the way it has always
> been.  You have to have an interface between the OS and user code and
> the C standard library forms part of the interface.

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!

I think those of us having to deal with two platforms (Unix and 
Windows), having to use other languages to implement low level programs 
(and having to implement such languages) coulld well have a broader 
perspective on all this stuff.

>> In the case of a simple version of atoi(), you would expect this to be
>> part of a library specific to a language.

> atoi() is part of the standard library, are you advocating breaking it
> up into simple bits and harder bits?  Where would you draw the line?

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.)

-- 
Bartc
0
BartC
12/24/2016 10:01:28 PM
On 24/12/2016 13:47, BartC wrote:

> https://github.com/bartg/langs/blob/master/ccp.md

https://en.wikipedia.org/wiki/Tiny_C_Compiler
https://stackoverflow.com/questions/584714/is-there-an-interpreter-for-c

0
Noob
12/24/2016 10:39:56 PM
BartC <bc@freeuk.com> 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  <http://www.ghoti.net/~kst>
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"
0
Keith
12/24/2016 11:21:46 PM
On Saturday, December 24, 2016 at 4:01:45 PM UTC-6, Bart wrote:

> 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.)
> 

Locales were added by the ISO for the first international
standard. A very good source for this info is P.J.Plauger
/The Standard C Library/.

0
luser
12/24/2016 11:29:34 PM
On 24/12/2016 22:39, Noob wrote:
> On 24/12/2016 13:47, BartC wrote:
>
>> https://github.com/bartg/langs/blob/master/ccp.md
>
> https://en.wikipedia.org/wiki/Tiny_C_Compiler

Yes, I've known about that for a couple of years (before that I thought 
it was just a toy, but it's not). In fact it meant I hadn't bothered 
with the idea of a C compiler sooner, as TCC proved you could get 
compile times in the 100's Kloc per second range, so it didn't need me 
to show that.

But some differences here: https://github.com/bartg/langs/blob/master/tcc.md

> https://stackoverflow.com/questions/584714/is-there-an-interpreter-for-c

That would be intriguing but I'm not planning an interpreted version.

-- 
Bartc
0
BartC
12/25/2016 12:32:44 AM
On 12/25/16 11:01 AM, BartC wrote:
> On 24/12/2016 20:43, Ian Collins wrote:
>> On 12/25/16 02:04 AM, BartC wrote:
>>> On 24/12/2016 03:46, Ian Collins wrote:
>>>> On 12/24/16 01:09 AM, BartC wrote:
>>>
>>>>> I don't know what else is needed to show that atoi() is an integral
>>>>> part
>>>>> of the language.
>>>>
>>>> Unix systems have always had their own standard library implementations.
>>>
>>> Of what? The C library?
>>
>> Isn't that what I wrote?
>>
>>> If so, do they have standard library implementations for Cobol, Lisp and
>>> K too? Do they have matrix-multiplication routines for maths languages?
>>
>> Why should they?  C is the interface language for the OS.
>
> It's the interface language for Windows too (or Win16 and early Win32;
> now they call the same interface a C++ one).
>
> But there the API is clearly not the C library. Win API functions must
> be accessed via cross-language and cross-compiler DLL files; you can't
> choose to statically link them into your program.

The Windows developers decided to ignore what was already there and 
developers have paid the price ever since.

> It's clear what is part of the language and what isn't. And that the Win
> API won't work under Unix.
>
>>> I think there is too much cosiness between C and Unix, such that you
>>> can't tell what is part of the language and what is part of the OS. That
>>> can make things confusing.
>>
>> Not really, the two grew up together and that's the way it has always
>> been.  You have to have an interface between the OS and user code and
>> the C standard library forms part of the interface.
>
> 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!

It's what is defined by the C standard and in the Unix world, POSIX.

> I think those of us having to deal with two platforms (Unix and
> Windows), having to use other languages to implement low level programs
> (and having to implement such languages) coulld well have a broader
> perspective on all this stuff.

Some of us have to deal with multiple platforms an languages, so our 
perspective is quite broad.

>>> In the case of a simple version of atoi(), you would expect this to be
>>> part of a library specific to a language.
>
>> atoi() is part of the standard library, are you advocating breaking it
>> up into simple bits and harder bits?  Where would you draw the line?
>
> No just the simple part.

As I asked, Where would you draw the line?

-- 
Ian
0
Ian
12/25/2016 3:53:19 AM
Reply: