Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > About -lm switch used for linking math.h

Reply
Thread Tools

About -lm switch used for linking math.h

 
 
Kenny McCormack
Guest
Posts: n/a
 
      01-27-2012
In article <(E-Mail Removed)>,
Kaz Kylheku <(E-Mail Removed)> wrote:
>On 2012-01-27, Wolfgang.Draxinger
><(E-Mail Removed)-muenchen.de> wrote:
>> library functions simply won't work. All compilers/linkers offer a
>> option, not to link against the standard library.

>
>Finally, someone in c.l.c. who has used all compilers.
>
>Man, have I got a lot of questions for you.


Good one!

--
They say compassion is a virtue, but I don't have the time!

- David Byrne -

 
Reply With Quote
 
 
 
 
Joe Pfeiffer
Guest
Posts: n/a
 
      01-27-2012
"Wolfgang.Draxinger" <(E-Mail Removed)-muenchen.de> writes:

> On Thu, 26 Jan 2012 23:09:23 -0700
> Joe Pfeiffer <(E-Mail Removed)> wrote:
>
>> 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 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.
 
Reply With Quote
 
 
 
 
Rui Maciel
Guest
Posts: n/a
 
      01-27-2012
Kenny McCormack wrote:

<snip/>
> 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
 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      01-27-2012
On 2012-01-27, Kenny McCormack <(E-Mail Removed)> wrote:
> In article <jful0l$d2v$(E-Mail Removed)>,
> Rui Maciel <(E-Mail Removed)> wrote:
>>Kenny McCormack wrote:
>>
>>> All versions of MS/PC DOS/Windows, since DOS 2.0, are
>>> Unix-based

>>
>>Do you actually have any basis for that assertion?
>>
>>
>>Rui Maciel

>
> 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
- ...
 
Reply With Quote
 
tom st denis
Guest
Posts: n/a
 
      01-27-2012
On Jan 27, 10:55*am, (E-Mail Removed) (Kenny McCormack)
wrote:
> In article <(E-Mail Removed)..com>,
> tom st denis *<(E-Mail Removed)> blubbered:
> ...
>
> >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.

>
> 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.
 
Reply With Quote
 
tom st denis
Guest
Posts: n/a
 
      01-27-2012
On Jan 27, 12:58*pm, Kaz Kylheku <(E-Mail Removed)> wrote:
> On 2012-01-27, Kenny McCormack <(E-Mail Removed)> wrote:
>
>
>
>
>
>
>
>
>
> > In article <jful0l$(E-Mail Removed)>,
> > Rui Maciel *<(E-Mail Removed)> wrote:
> >>Kenny McCormack wrote:

>
> >>> All versions of MS/PC DOS/Windows, since DOS 2.0, are
> >>> Unix-based

>
> >>Do you actually have any basis for that assertion?

>
> >>Rui Maciel

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


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
 
Reply With Quote
 
Stephen Sprunk
Guest
Posts: n/a
 
      01-27-2012
On 27-Jan-12 00:09, Joe Pfeiffer wrote:
> 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

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      01-27-2012
"Stephen Sprunk" <(E-Mail Removed)> wrote in message
news:jfuq77$qrj$(E-Mail Removed)...

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

--
Bartc

 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      01-27-2012
On 01/27/2012 01:41 PM, BartC wrote:
> "Stephen Sprunk" <(E-Mail Removed)> wrote in message
> news:jfuq77$qrj$(E-Mail Removed)...

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


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

typedef _Bool bool;
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-27-2012
tom st denis <(E-Mail Removed)> writes:
> On Jan 27, 9:43*am, (E-Mail 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.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
linking 2 VLANs on one switch rezalas Hardware 3 05-17-2008 04:23 AM
Switch/Switch problem fibre gigbit ethernet hartmut.albers@gmail.com Cisco 2 09-06-2005 04:59 PM
Is a frame switch and an ISDN switch really needed? owmanstubbedmytoe Cisco 2 12-05-2004 07:15 AM
bridge / layer 2 switch / layer 3 switch Joel M. Baldwin Cisco 2 11-06-2003 11:19 PM
difference b/w layer 2 switch and layer 3 switch praveen Cisco 1 10-22-2003 07:19 AM



Advertisments