Standard C and math library

[Sensei]

I have a quick question about the math library included in the standard
C90 (and 99).

The gcc, xlc and possibly other compilers/linkers on some unix
platforms cannot use any math functions in math.h if a switch (-lm) is
used, so *explicitly* having the linker use a file called libm.so or
libm.a/dylib/whatever.

Is it true on all the platforms? (answer: probably no)

Is this a break on the standard?

Since abs(), sqrt() and all the math.h defined funcions/types ARE
(correct me if I make a mistake) put into the ISO C, any compiler and
any linker should NOT use an external library other than the standard C
library for those funcions. Is it so? Is the libc defined in the
standard having also math.h? If not, the separation seems to say ``math
is not in the standard c library, you must use something from outside''.

 

[Artie Gold]

I have a quick question about the math library included in the standard
C90 (and 99).

The gcc, xlc and possibly other compilers/linkers on some unix platforms
cannot use any math functions in math.h if a switch (-lm) is used, so
*explicitly* having the linker use a file called libm.so or
libm.a/dylib/whatever.

Is it true on all the platforms? (answer: probably no)

Is this a break on the standard?

No, it's not -- specifically because the standard says nothing about how
programs are compiled or linked.

Since abs(), sqrt() and all the math.h defined funcions/types ARE
(correct me if I make a mistake) put into the ISO C, any compiler and
any linker should NOT use an external library other than the standard C
library for those funcions. Is it so? Is the libc defined in the
standard having also math.h? If not, the separation seems to say ``math
is not in the standard c library, you must use something from outside''.

No, the math functions *are* in the standard library -- but, again,
since the magic words used for compilation and linking are external to
the standard, it doesn't matter.

[In a lot of ways, it's a strange historical wart; I suspect you don't
remember the days of external floating point coprocessors and such. In
addition, unlike today where it's mostly embedded systems (and
particularly memory constrained ones at that) where memory footprint
matters at that level of granularity, it once *did* matter --
particularly at the time the convention was adopted.

Periodically, a plea is made to make the standard library monolithic on
*nix systems -- and perhaps one day it will occur.]

HTH,
--ag

 

[Anonymous 7843]

[In a lot of ways, it's a strange historical wart; I suspect you don't
remember the days of external floating point coprocessors and such. In
addition, unlike today where it's mostly embedded systems (and
particularly memory constrained ones at that) where memory footprint
matters at that level of granularity, it once *did* matter --
particularly at the time the convention was adopted.

It was strange even then. Any static linker would strip out unused
math functions or simply skip them in the first place. It was unlikely
that "-lm" would bloat your program if you didn't actually use any
floating point stuff.

But sometimes, "-lm" meant not to just link in fp libraries, but
to take an extra pass over the code and do some inlining of
hand-optimized assembly to replace certain fp operations, depending
on what stuff your fpu actually did in hardware vs. what your
program called for. The extra pass could actually take up some
cpu time and back then we didn't have a lot to spare.

 

[Eric Sosman]

[In a lot of ways, it's a strange historical wart; I suspect you don't
remember the days of external floating point coprocessors and such. In
addition, unlike today where it's mostly embedded systems (and
particularly memory constrained ones at that) where memory footprint
matters at that level of granularity, it once *did* matter --
particularly at the time the convention was adopted.

It was strange even then. Any static linker would strip out unused
math functions or simply skip them in the first place. It was unlikely
that "-lm" would bloat your program if you didn't actually use any
floating point stuff.

Not so strange, really. The linker that needed to make
a pass over a great big barrel of functions that weren't used
required time to do so, and the time to pass over and ignore
all those math functions (count them; they are, one might say,
numer-ous) was noticeable. If you argue against separable
math libraries in 197x, you argue against precompiled headers
today -- it's a matter of scale, nothing more.

 

[Dik T. Winter]

> Not so strange, really. The linker that needed to make
> a pass over a great big barrel of functions that weren't used
> required time to do so, and the time to pass over and ignore
> all those math functions (count them; they are, one might say,
> numer-ous) was noticeable.

Not really. Back in the early 70s I used a CDC Cyber for my work.
Most common was *not* to prelink before execution. It was on
execution that the linker came into play and created the binary
actually used. Linking from the compiled (relocatable) binary
to an executable took no noticable time. Consider a Fortran source
consisting of a few hundred subroutines. When compiling, each
routine was compiled on its own, relocatable, and whatever. When
executing you just entered LGO and linking and whatever began.
You could do all that before execution (and make the equivalent of
an EXE), but in most cases it was not worth the trouble. Linking
took no noticable time. For me it was really a culture shock when
I shifted to Unix. It took really extremely much time just to link.
(And to put it in perspective, that CDC machine had 65536 60-bits
words of memory, and served about 100 interactive users. The
interactive response was not worse than what I am getting at my
workstation.)

 

[Gordon Burditt]

[In a lot of ways, it's a strange historical wart; I suspect you don't

It was strange even then. Any static linker would strip out unused
math functions or simply skip them in the first place. It was unlikely
that "-lm" would bloat your program if you didn't actually use any
floating point stuff.

The tricks get cuter than that. For example, some implementations
have two copies of printf(), one with floating point support and
one without it. The one with floating point support would drag in
other internal functions that wouldn't be used without floating
point support (for example, the routines that formatted floating-point
numbers as text). All this was based on implementor-known order
of loading functions in case there were more than one with the same
name. I believe at least one required use of -lm to get the version
of printf() which used floating point.

But sometimes, "-lm" meant not to just link in fp libraries, but
to take an extra pass over the code and do some inlining of
hand-optimized assembly to replace certain fp operations, depending
on what stuff your fpu actually did in hardware vs. what your
program called for. The extra pass could actually take up some
cpu time and back then we didn't have a lot to spare.

Gordon L. Burditt

 

[CBFalconer]

I have a quick question about the math library included in the
standard C90 (and 99).

The gcc, xlc and possibly other compilers/linkers on some unix
platforms cannot use any math functions in math.h if a switch (-lm)
is used, so *explicitly* having the linker use a file called
libm.so or libm.a/dylib/whatever.

Is it true on all the platforms? (answer: probably no)

Is this a break on the standard?

Since abs(), sqrt() and all the math.h defined funcions/types ARE
(correct me if I make a mistake) put into the ISO C, any compiler
and any linker should NOT use an external library other than the
standard C library for those funcions. Is it so? Is the libc
defined in the standard having also math.h? If not, the separation
seems to say ``math is not in the standard c library, you must use
something from outside''.

The standard says what facilities are to be available, and what
include files to specify. It DOES NOT specify a mechanism for
running the system, such as "pull lever A, wait for a ball to pop
out of slot B, then throw toggle switch C". For that you have to
look to your compiler/system documentation, and anything goes.

 

[Sensei]

No, it's not -- specifically because the standard says nothing about
how programs are compiled or linked.

Ah! Ok.

No, the math functions *are* in the standard library -- but, again,
since the magic words used for compilation and linking are external to
the standard, it doesn't matter.

I see.

[In a lot of ways, it's a strange historical wart; I suspect you don't
remember the days of external floating point coprocessors and such. In
addition, unlike today where it's mostly embedded systems (and
particularly memory constrained ones at that) where memory footprint
matters at that level of granularity, it once *did* matter --
particularly at the time the convention was adopted.

Well, I've grown under C64 and Prodest, I had a 286 without 287
coprocessor... I know history in this case Anyway the standard C99
is far too young to be affected by math coprocessors and DX/SX
distinction. That's why I'm puzzled.

odically, a plea is made to make the standard library monolithic on
*nix systems -- and perhaps one day it will occur.]

One thing I thought is that using floating point library when not
needed would be a ``waste of space''... even though is just some kb...

 

[Mark McIntyre]

On Wed, 13 Jul 2005 01:18:35 GMT, in comp.lang.c ,

It was strange even then. Any static linker would strip out unused
math functions or simply skip them in the first place.

Euh, in the Olden Days, the time taken to run through and decide you
didn't need the stuff was appreciable. Imagine linking one of today's
apps on a 4.77Mhz chip.....

It was unlikely
that "-lm" would bloat your program if you didn't actually use any
floating point stuff.

Some compiler suites were especially braindead and included all
functions in Library X, whether or not you used them. Some still do
(try this with MFC sometime...) Its a QOI issue.