About -lm switch used for linking math.h

[Kenny McCormack]

Finally, someone in c.l.c. who has used all compilers.

Man, have I got a lot of questions for you.

Good one!

 

[Joe Pfeiffer]

Because you may be able to compile and link without the C standard
library functions being available. Like when boostrapping the standard
library or implementing a operating system kernel, where the standard
library functions simply won't work. All compilers/linkers offer a
option, not to link against the standard library.

I don't see where having the standard prototypes automatically available
conflicts with this; there are several ways to do that and still have
the ability to compile without linking against the standard library.
The most straightforward would be to have the same option that disables
the linking also disable automatic prototypes.

 

[Rui Maciel]

Kenny McCormack wrote:

DOS 1 was, as Tommy notes, basically a quick hack-up of CP/M, but
DOS 2 introduced a lot of Unixy stuff and made DOS quite Unix-like.

Again, do you actually have any basis for that assertion? I mean, where
exactly do you see DOS as being "quite Unix-like"?


Rui Maciel

 

[Kaz Kylheku]

I do not mean "based" in the sense of "code based" - i.e., that they took
Unix code to build DOS. Only a moronic pedant would think that - which is
why we are seeing so much of it in this thread. See: "straw man".

I mean "based" in the sense of "ideas borrowed from". And I mean borrowed
rather heavily - not just a smidgen here and there.

It is obvious to anyone with two brain cells to rub together that DOS
imitates Unix:

- the current directory is . and the parent ..
- forward slash separation of paths (but backslash also).
- command pipes denoted by |
- redirection with < and >
- some similar commands like "cd"
- devices (COM1: LPT1: CON ...) in the file namespace
- ...

 

[tom st denis]

It all depends on what the meaning of the word "based" is.

I'm "basing" it on the fact that you're a moron, and I am not.

 

[tom st denis]

It is obvious to anyone with two brain cells to rub together that DOS
imitates Unix:

- the current directory is . and the parent ..
- forward slash separation of paths (but backslash also).
- command pipes denoted by |
- redirection with < and >
- some similar commands like "cd"
- devices (COM1: LPT1: CON ...) in the file namespace
- ...

It lacks users, doesn't have multi-tasking, or IPC, has no memory
protection, file attributes beyond "user" [no other/group], has no
concept of networking, development tools, etc.

Ya, DOS is JUST LIKE UNIX!!!

*yawn*

Tom

 

[Stephen Sprunk]

The better question would be why the C standard library function
prototypes aren't all automatically available, without a bunch of
#include's. To me it seems like they ought to be, but the people
writing the standards and the people writing the compilers don't agree
with me, so they aren't.

The most obvious answer is that it would cause problems whenever new
functions were added to the standard library; if those prototypes (and
types, macros, etc.) were automatically available, then it would break
existing code that used those names. Putting them in headers that
programmers specifically have to include will reduce that impact.

A perfect case in point is <stdbool.h>; lots of folks were already using
"bool" to refer to their own boolean typedef, so putting the standard
boolean typedef in its own header was the only workable solution.

Also, while it is not required, the usual way of implementing the
standard headers is for them to be actual files just like any other
header. Automatically including them means that those files would have
to be processed even if the code didn't actually need them. That's less
of an issue today, but it was a big issue back when C was being
standardized.

S

 

[BartC]

The most obvious answer is that it would cause problems whenever new
functions were added to the standard library ...

A perfect case in point is <stdbool.h>; lots of folks were already using
"bool" to refer to their own boolean typedef, so putting the standard
boolean typedef in its own header was the only workable solution.

I thought the standard boolean type was _Bool? Then it shouldn't be any
problem unless the user naughtily used _Bool for his own type (and
presumably with his own reasons for deliberately choosing such an
ugly-looking type name).

Also, while it is not required, the usual way of implementing the
standard headers is for them to be actual files just like any other
header. Automatically including them means that those files would have
to be processed even if the code didn't actually need them.

Automatically including them means they needn't be files at all. All those
definitions can just pre-exist in the compiler. (That's if compilers don't
already work like that: by seeing 'stdio.h' and turning on those definitions
rather than go to the trouble of processing an actual file.) Obviously there
would need to be mechanism to turn off or override any built-in definitions
with user-supplied headers.)

 

[James Kuyper]

I thought the standard boolean type was _Bool? Then it shouldn't be any
problem unless the user naughtily used _Bool for his own type (and
presumably with his own reasons for deliberately choosing such an
ugly-looking type name).

Yes, _Bool is the standard name, but <stdbool.h> contains something
equivalent to

typedef _Bool bool;

 

[Keith Thompson]

On Jan 27, 9:43 am, (e-mail address removed) (Kenny McCormack)
wrote: [snip]

So not only are your posts tiresome and boring but they're wholesale
factually incorrect even when you are trying to be a smarty pants.

Please don't feed the troll.

 

[Kenny McCormack]

It is obvious to anyone with two brain cells to rub together that DOS
imitates Unix:

- the current directory is . and the parent ..
- forward slash separation of paths (but backslash also).
- command pipes denoted by |
- redirection with < and >
- some similar commands like "cd"
- devices (COM1: LPT1: CON ...) in the file namespace
- ...

Thank you. Somebody who gets it.

(That is: Is willing to post honestly, and leave ideological considerations
aside)

--
But the Bush apologists hope that you won't remember all that. And they
also have a theory, which I've been hearing more and more - namely,
that President Obama, though not yet in office or even elected, caused the
2008 slump. You see, people were worried in advance about his future
policies, and that's what caused the economy to tank. Seriously.

(Paul Krugman - Addicted to Bush)

 

[Keith Thompson]

Yes, _Bool is the standard name, but <stdbool.h> contains something
equivalent to

typedef _Bool bool;

Actually it contains something equivalent to:

#define _Bool bool
#define true 1
#define false 0
#define __bool_true_false_are_defined 1

So yes, having an implicit #include <stdbool.h> for all programs would
break programs that define "bool", "true", and/or "false" for their own
purposes.

 

[Joe keane]

The better question would be why the C standard library function
prototypes aren't all automatically available, without a bunch of
#include's. To me it seems like they ought to be, but the people
writing the standards and the people writing the compilers don't agree
with me, so they aren't.

Because the C standard mainly codified existing practice.

One day, C was just a language. People wrote some utility functions.
If you want a function and it isn't in your program, you copy it from
one that does have it. If you for some unknown reason want a
declaration, of course that should go in a header file.

Eventually, people settled on a more-or-less standard C library, that
contains stuff like stdio that 'everyone' needs. And then, there's a
math library; many programs don't need that stuff. And then, there's
the X library; suprisingly many programs don't do graphics.

 

[Malcolm McLean]

One day, C was just a language.  People wrote some utility functions.

Most languages had input and output statements. Many had special built
in functions.

C was a bit different. Everything in the language proper mapped to two
or three assembly instructions. Everything else was a function. There
was no difference between user-defined functions and built in ines,
and virtually every function could be implemented in C.

The library grew up with the language, however.

 

[Ian Collins]

Most languages had input and output statements. Many had special built
in functions.

C was a bit different. Everything in the language proper mapped to two
or three assembly instructions. Everything else was a function. There
was no difference between user-defined functions and built in ines,
and virtually every function could be implemented in C.

The library grew up with the language, however.

The library also grew to be pretty big in comparison with the "standard"
library. On early machines there wasn't any hardware floating point
support and RAM was a precious resource, so a separate library made sense.

 

[BartC]

The library also grew to be pretty big in comparison with the "standard"
library. On early machines there wasn't any hardware floating point
support and RAM was a precious resource, so a separate library made sense.

Perhaps I no longer understand what the purpose of a linker is, but I
thought that they extracted only the functions that were needed from a
library (and any further functions that *they* depend on). It was not
necessary to load the entire library. So linking in a maths module should
not make the program any bigger, if no maths functions are actually used.

(Certainly, when I one time decided to dispense with the services of a
linker, and wrote my own loader, that loader was very fast just because it
*did* just load libraries in their entirety.)

 

[Jens Thoms Toerring]

It is obvious to anyone with two brain cells to rub together that DOS
imitates Unix:

- the current directory is . and the parent ..
- forward slash separation of paths (but backslash also).
- command pipes denoted by |
- redirection with < and >
- some similar commands like "cd"
- devices (COM1: LPT1: CON ...) in the file namespace
- ...

In just the same way the intelligent designer based the mosquito
design on that of the human (or was it the other way round?):

- both have two eyes
- both have a mouth
- both have legs
- both have nerve cells (hopefully)
- both breath oxygen
- ...

;-)

 

[Jens Gustedt]

Am 01/27/2012 07:41 PM, schrieb BartC:

"Stephen Sprunk" <[email protected]> wrote in message

Automatically including them means they needn't be files at all.
All
those definitions can just pre-exist in the compiler. (That's if
compilers don't already work like that: by seeing 'stdio.h' and turning
on those definitions rather than go to the trouble of processing an
actual file.) Obviously there would need to be mechanism to turn off or
override any built-in definitions with user-supplied headers.)

But current standard already allows for that. It doesn't enforce
standard headers to be files. Any other mechanism that make the
declarations that belong to a standard header available is permitted.
(But why shouldn't they use files, nowadays. Reading a lot of source
files is usually not the bottleneck in compilation.)


On the other hand, you also have explicit rules in the standard which
headers make what symbols available. So if you don't use such a specific
header, the identifiers in there will not conflict with names in your
application. E.g the complex.h header defines the macro "I", this easily
conflicts with existing praxis in some code.

Jens

 

[James Kuyper]

Perhaps I no longer understand what the purpose of a linker is, but I
thought that they extracted only the functions that were needed from a
library (and any further functions that *they* depend on). It was not
necessary to load the entire library. So linking in a maths module should
not make the program any bigger, if no maths functions are actually used.

The size of unused library functions wasn't the issue; the time spent
searching the library to see whether there was a correspondingly named
function was the problem. Hard as that might be to imagine now, at one
time that was a serious constraint on the build time of programs.

 

[Stephen Sprunk]

I thought the standard boolean type was _Bool? Then it shouldn't be any
problem unless the user naughtily used _Bool for his own type (and
presumably with his own reasons for deliberately choosing such an
ugly-looking type name).

"_Bool" is a hack around the fact there is no way to introduce a new
basic type in a header file. "bool" is what the standard was really
trying to introduce, but that is a typedef to "_Bool" that one gets by
including <stdbool.h>.

I'm not sure why "bool" isn't simply a typedef to some existing integer
type, which was common practice prior to _Bool being added to the
language. Perhaps knowing a variable is boolean allows compilers to
make more aggressive optimizations that would be unsafe for other
integer types.

Automatically including them means they needn't be files at all. All
those definitions can just pre-exist in the compiler. (That's if
compilers don't already work like that: by seeing 'stdio.h' and turning
on those definitions rather than go to the trouble of processing an
actual file.) Obviously there would need to be mechanism to turn off or
override any built-in definitions with user-supplied headers.)

There is nothing stopping an implementation from doing that today; in
fact, it seems as if the standard goes to pains to allow that, so I'm
guessing at least one implementation does/did that. However, that
shouldn't be _forced_ on compilers, especially since (AFAIK) that is not
the norm.

S