Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #16269 > unrolled thread
| Started by | Avinash Sonawane <avinash.sonawane1990@gmail.com> |
|---|---|
| First post | 2012-01-26 13:59 -0800 |
| Last post | 2012-01-27 11:12 -0600 |
| Articles | 20 on this page of 100 — 30 participants |
Back to article view | Back to comp.lang.c
About -lm switch used for linking math.h Avinash Sonawane <avinash.sonawane1990@gmail.com> - 2012-01-26 13:59 -0800
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-26 14:15 -0800
Re: About -lm switch used for linking math.h James Kuyper <jameskuyper@verizon.net> - 2012-01-26 17:17 -0500
Re: About -lm switch used for linking math.h Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-26 20:54 -0500
Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-27 02:12 +0000
Re: About -lm switch used for linking math.h jacob navia <jacob@spamsink.net> - 2012-01-26 23:29 +0100
Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-26 23:09 -0700
Re: About -lm switch used for linking math.h jacob navia <jacob@spamsink.net> - 2012-01-27 08:37 +0100
Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 09:48 +0000
OT:Re: About -lm switch used for linking math.h Kleuske <kleuske@nowhere.net> - 2012-01-27 10:15 +0000
Re: OT:Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 14:43 +0000
Re: OT:Re: About -lm switch used for linking math.h tom st denis <tom@iahu.ca> - 2012-01-27 07:49 -0800
Re: OT:Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 15:55 +0000
Re: OT:Re: About -lm switch used for linking math.h tom st denis <tom@iahu.ca> - 2012-01-27 10:14 -0800
Re: OT:Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 11:23 -0800
Re: OT:Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-27 09:42 -0700
Re: OT:Re: About -lm switch used for linking math.h 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-28 14:08 -0800
Re: OT:Re: About -lm switch used for linking math.h Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-14 13:14 +0200
Re: About -lm switch used for linking math.h Rui Maciel <rui.maciel@gmail.com> - 2012-01-27 16:56 +0000
Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 17:34 +0000
Re: About -lm switch used for linking math.h Rui Maciel <rui.maciel@gmail.com> - 2012-01-27 17:50 +0000
Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-27 17:58 +0000
Re: About -lm switch used for linking math.h tom st denis <tom@iahu.ca> - 2012-01-27 10:15 -0800
Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 19:25 +0000
Re: About -lm switch used for linking math.h Kleuske <kleuske@nowhere.net> - 2012-01-28 18:09 +0000
Re: About -lm switch used for linking math.h jt@toerring.de (Jens Thoms Toerring) - 2012-01-27 21:32 +0000
Re: About -lm switch used for linking math.h "Wolfgang.Draxinger" <Wolfgang.Draxinger@physik.uni-muenchen.de> - 2012-01-27 12:40 +0100
Re: About -lm switch used for linking math.h "BartC" <bc@freeuk.com> - 2012-01-27 12:48 +0000
Re: About -lm switch used for linking math.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-27 14:28 +0000
Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-27 17:14 +0000
Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 17:34 +0000
Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-27 10:43 -0700
Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-27 12:25 -0600
Re: About -lm switch used for linking math.h "BartC" <bc@freeuk.com> - 2012-01-27 18:41 +0000
Re: About -lm switch used for linking math.h James Kuyper <jameskuyper@verizon.net> - 2012-01-27 13:45 -0500
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 11:29 -0800
Re: About -lm switch used for linking math.h Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-27 22:35 +0100
Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-27 17:19 -0600
Re: About -lm switch used for linking math.h James Kuyper <jameskuyper@verizon.net> - 2012-01-27 19:22 -0500
Re: About -lm switch used for linking math.h Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 23:32 -0800
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 16:26 -0800
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 13:30 +1300
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 17:04 -0800
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 14:10 +1300
Re: About -lm switch used for linking math.h Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-27 21:06 -0500
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 20:09 -0800
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 20:15 -0800
Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-27 23:03 -0600
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 19:10 +1300
Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-28 04:28 -0800
Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-28 15:25 -0600
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-29 11:39 +1300
Re: About -lm switch used for linking math.h Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-29 09:53 -0800
Re: About -lm switch used for linking math.h Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-03 10:39 +0000
Re: About -lm switch used for linking math.h Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-01 16:42 -0800
Re: About -lm switch used for linking math.h jgk@panix.com (Joe keane) - 2012-02-02 01:29 +0000
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-28 15:22 -0800
Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-29 16:52 -0600
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-30 02:04 -0800
Re: About -lm switch used for linking math.h Ike Naar <ike@iceland.freeshell.org> - 2012-01-30 10:22 +0000
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-30 02:36 -0800
Re: About -lm switch used for linking math.h Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-14 13:33 +0200
Re: About -lm switch used for linking math.h Ike Naar <ike@iceland.freeshell.org> - 2012-02-14 23:48 +0000
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-02-14 16:35 -0800
Re: About -lm switch used for linking math.h Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-22 02:44 +0200
Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-30 04:30 -0800
Re: About -lm switch used for linking math.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-30 14:36 +0000
Re: About -lm switch used for linking math.h Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 23:50 -0800
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-28 15:29 -0800
Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-29 09:11 -0800
Re: About -lm switch used for linking math.h "BartC" <bc@freeuk.com> - 2012-01-29 17:49 +0000
Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-29 10:07 -0800
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-29 14:24 -0800
Re: About -lm switch used for linking math.h Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-29 09:43 -0800
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 16:54 -0800
Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-28 01:09 +0000
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 14:20 +1300
Re: About -lm switch used for linking math.h Azazel <azazel@remove.azazel.net> - 2012-01-30 17:40 -0600
Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-31 00:05 +0000
Re: About -lm switch used for linking math.h jgk@panix.com (Joe keane) - 2012-01-27 20:03 +0000
Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-27 12:26 -0800
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 10:24 +1300
Re: About -lm switch used for linking math.h "BartC" <bc@freeuk.com> - 2012-01-27 21:32 +0000
Re: About -lm switch used for linking math.h James Kuyper <jameskuyper@verizon.net> - 2012-01-27 16:39 -0500
Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-27 23:24 -0600
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 20:38 +1300
Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-28 02:17 -0600
Re: About -lm switch used for linking math.h Richard Damon <news.x.richarddamon@xoxy.net> - 2012-01-28 14:07 -0500
Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-28 15:07 -0600
Re: About -lm switch used for linking math.h jgk@panix.com (Joe keane) - 2012-01-28 21:09 +0000
Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-27 21:39 -0700
Re: About -lm switch used for linking math.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-28 11:21 +0000
Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-28 17:51 -0700
Re: About -lm switch used for linking math.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-29 02:03 +0000
Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-28 18:58 +0000
Re: About -lm switch used for linking math.h jacob navia <jacob@spamsink.net> - 2012-01-28 20:48 +0100
Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-28 22:54 -0600
Re: About -lm switch used for linking math.h jgk@panix.com (Joe keane) - 2012-01-29 21:42 +0000
Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-30 00:14 -0600
Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-27 11:12 -0600
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2012-01-27 17:50 +0000 |
| Message-ID | <jfuo4u$kcn$2@speranza.aioe.org> |
| In reply to | #16295 |
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
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2012-01-27 17:58 +0000 |
| Message-ID | <20120127094931.108@kylheku.com> |
| In reply to | #16295 |
On 2012-01-27, Kenny McCormack <gazelle@shell.xmission.com> wrote: > In article <jful0l$d2v$1@speranza.aioe.org>, > Rui Maciel <rui.maciel@gmail.com> 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 - ...
[toc] | [prev] | [next] | [standalone]
| From | tom st denis <tom@iahu.ca> |
|---|---|
| Date | 2012-01-27 10:15 -0800 |
| Message-ID | <1e38b3a6-beea-4e7d-9a67-19f4bdbfe1ae@c21g2000yqi.googlegroups.com> |
| In reply to | #16299 |
On Jan 27, 12:58 pm, Kaz Kylheku <k...@kylheku.com> wrote: > On 2012-01-27, Kenny McCormack <gaze...@shell.xmission.com> wrote: > > > > > > > > > > > In article <jful0l$d2...@speranza.aioe.org>, > > Rui Maciel <rui.mac...@gmail.com> 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
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2012-01-27 19:25 +0000 |
| Message-ID | <jfuto6$1ii$1@news.xmission.com> |
| In reply to | #16299 |
In article <20120127094931.108@kylheku.com>,
Kaz Kylheku <kaz@kylheku.com> wrote:
>On 2012-01-27, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <jful0l$d2v$1@speranza.aioe.org>,
>> Rui Maciel <rui.maciel@gmail.com> 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
>- ...
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)
[toc] | [prev] | [next] | [standalone]
| From | Kleuske <kleuske@nowhere.net> |
|---|---|
| Date | 2012-01-28 18:09 +0000 |
| Message-ID | <jg1dk7$99b$2@dont-email.me> |
| In reply to | #16306 |
On Fri, 27 Jan 2012 19:25:58 +0000, Kenny McCormack saw fit to publish the following: <snip> >>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) It's like saying a 2CV was based on a Mercedes Benz, since both have four wheels. It did have a BMW motor, though. -- Spock: The odds of surviving another attack are 13562190123 to 1, Captain.
[toc] | [prev] | [next] | [standalone]
| From | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Date | 2012-01-27 21:32 +0000 |
| Message-ID | <9ogjflFmbhU1@mid.uni-berlin.de> |
| In reply to | #16299 |
Kaz Kylheku <kaz@kylheku.com> wrote: > On 2012-01-27, Kenny McCormack <gazelle@shell.xmission.com> wrote: > > In article <jful0l$d2v$1@speranza.aioe.org>, > > Rui Maciel <rui.maciel@gmail.com> 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 > - ... 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 Thoms Toerring ___ jt@toerring.de \__________________________ http://toerring.de
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang.Draxinger" <Wolfgang.Draxinger@physik.uni-muenchen.de> |
|---|---|
| Date | 2012-01-27 12:40 +0100 |
| Message-ID | <20120127124032.783fb0ed@cip38.cip.physik.uni-muenchen.de> |
| In reply to | #16279 |
On Thu, 26 Jan 2012 23:09:23 -0700 Joe Pfeiffer <pfeiffer@cs.nmsu.edu> 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. Wolfgang
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-01-27 12:48 +0000 |
| Message-ID | <jfu6f6$8od$1@dont-email.me> |
| In reply to | #16285 |
"Wolfgang.Draxinger" <Wolfgang.Draxinger@physik.uni-muenchen.de> wrote in message news:20120127124032.783fb0ed@cip38.cip.physik.uni-muenchen.de... > On Thu, 26 Jan 2012 23:09:23 -0700 > Joe Pfeiffer <pfeiffer@cs.nmsu.edu> 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. I suppose it's simple enough to bundle all the standard headers into one big header, and to just include that. That's saves having the ridiculous situation of having to keep deleting or adding include files, everything time you edit some code and the number of references to something in a standard header, falls below 1, or rises above zero. How do you keep track of something like that anyway? So you just keep a whole bunch of headers in, whether they are essential or not. The only problem is that an all-inclusive header file is not standardised (or is it?) making it more difficult to share code. > 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. Those are special cases, ordinary programmers shouldn't be burdened with maintaining lists of include files just so 1% of all programmers have the option of leaving them out! Actually it would be simplest for the compiler to just include everything necessary (to be able to write C code), and for a compiler switch to say headers are included manually. > All compilers/linkers offer a > option, not to link against the standard library. So why not a switch to *not* include the maths library, rather than the other way around? Is the maths library actually that big? And would it be statically linked in? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-01-27 14:28 +0000 |
| Message-ID | <0.b5a4e9d2f59dd1a71b68.20120127142801GMT.87ehulqky6.fsf@bsb.me.uk> |
| In reply to | #16286 |
"BartC" <bc@freeuk.com> writes: > "Wolfgang.Draxinger" <Wolfgang.Draxinger@physik.uni-muenchen.de> wrote in > message news:20120127124032.783fb0ed@cip38.cip.physik.uni-muenchen.de... >> On Thu, 26 Jan 2012 23:09:23 -0700 >> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> 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. > > I suppose it's simple enough to bundle all the standard headers into one big > header, and to just include that. <snip> > The only problem is that an all-inclusive header file is not standardised > (or is it?) making it more difficult to share code. But since the list of standard headers is standardised, you could distribute a .h file that includes them all along with the code you want to share. >> 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. > > Those are special cases, ordinary programmers shouldn't be burdened > with maintaining lists of include files just so 1% of all programmers > have the option of leaving them out! > > Actually it would be simplest for the compiler to just include everything > necessary (to be able to write C code), and for a compiler switch to say > headers are included manually. Some environments let you make such a compiler in a few minutes. gcc has a -include command-line option (and you can read options from a file with @file) so an alias like "gcc -std=c99 -pedantic @std-includes" does what you want. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2012-01-27 17:14 +0000 |
| Message-ID | <20120127091318.501@kylheku.com> |
| In reply to | #16285 |
On 2012-01-27, Wolfgang.Draxinger <Wolfgang.Draxinger@physik.uni-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.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2012-01-27 17:34 +0000 |
| Message-ID | <jfun7n$q19$2@news.xmission.com> |
| In reply to | #16294 |
In article <20120127091318.501@kylheku.com>,
Kaz Kylheku <kaz@kylheku.com> wrote:
>On 2012-01-27, Wolfgang.Draxinger
><Wolfgang.Draxinger@physik.uni-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 -
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2012-01-27 10:43 -0700 |
| Message-ID | <1baa59ujlk.fsf@pfeifferfamily.net> |
| In reply to | #16285 |
"Wolfgang.Draxinger" <Wolfgang.Draxinger@physik.uni-muenchen.de> writes: > On Thu, 26 Jan 2012 23:09:23 -0700 > Joe Pfeiffer <pfeiffer@cs.nmsu.edu> 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.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2012-01-27 12:25 -0600 |
| Message-ID | <jfuq77$qrj$1@dont-email.me> |
| In reply to | #16279 |
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
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-01-27 18:41 +0000 |
| Message-ID | <jfur4p$9t$1@dont-email.me> |
| In reply to | #16302 |
"Stephen Sprunk" <stephen@sprunk.org> wrote in message news:jfuq77$qrj$1@dont-email.me... > 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
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-01-27 13:45 -0500 |
| Message-ID | <4F22F0E1.2040004@verizon.net> |
| In reply to | #16303 |
On 01/27/2012 01:41 PM, BartC wrote: > "Stephen Sprunk" <stephen@sprunk.org> wrote in message > news:jfuq77$qrj$1@dont-email.me... ... >> 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;
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-01-27 11:29 -0800 |
| Message-ID | <lnhazh2bc4.fsf@nuthaus.mib.org> |
| In reply to | #16304 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 01/27/2012 01:41 PM, BartC wrote:
>> "Stephen Sprunk" <stephen@sprunk.org> wrote in message
>> news:jfuq77$qrj$1@dont-email.me...
> ...
>>> 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;
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.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <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"
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-01-27 22:35 +0100 |
| Message-ID | <4F231885.8040509@loria.fr> |
| In reply to | #16303 |
Am 01/27/2012 07:41 PM, schrieb BartC: > "Stephen Sprunk" <stephen@sprunk.org> 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
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2012-01-27 17:19 -0600 |
| Message-ID | <jfvbdt$1uc$1@dont-email.me> |
| In reply to | #16303 |
On 27-Jan-12 12:41, BartC wrote: > "Stephen Sprunk" <stephen@sprunk.org> wrote in message > news:jfuq77$qrj$1@dont-email.me... > >> 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). "_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. >> 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.) 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 -- 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
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-01-27 19:22 -0500 |
| Message-ID | <jfvf41$o42$1@dont-email.me> |
| In reply to | #16322 |
On 01/27/2012 06:19 PM, Stephen Sprunk wrote: ... > 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. The behavior of _Bool is different from any other unsigned integer type in two ways: * It has an integer conversion rank lower than any other standard integer type. * (_Bool)expression is equivalent to ((expression) != 0). -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2012-01-31 23:32 -0800 |
| Message-ID | <kfnk447xb37.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #16324 |
James Kuyper <jameskuyper@verizon.net> writes: > On 01/27/2012 06:19 PM, Stephen Sprunk wrote: > ... >> 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. > > The behavior of _Bool is different from any other unsigned integer type > in two ways: > * It has an integer conversion rank lower than any other standard > integer type. > * (_Bool)expression is equivalent to ((expression) != 0). And (3), assigning a pointer type to a _Bool is allowed without having to use a cast.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web