Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #101278 > unrolled thread
| Started by | Michael Holiday <Mike@example.invalid> |
|---|---|
| First post | 2017-01-07 23:49 -0800 |
| Last post | 2017-01-12 13:33 -0500 |
| Articles | 11 on this page of 71 — 18 participants |
Back to article view | Back to comp.lang.c
linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-07 23:49 -0800
Re: linking precedence rules Ian Collins <ian-news@hotmail.com> - 2017-01-08 21:20 +1300
Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-08 01:32 -0800
Re: linking precedence rules "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-08 11:08 -0500
Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-12 03:25 -0800
Re: linking precedence rules Noob <root@127.0.0.1> - 2017-01-12 13:31 +0100
OT Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-14 01:18 -0800
Re: linking precedence rules Barry Schwarz <schwarzb@dqel.com> - 2017-01-08 15:38 -0800
Re: linking precedence rules "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-08 18:46 -0500
Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-12 04:13 -0800
Re: linking precedence rules Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 12:21 +0000
Re: linking precedence rules Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 00:23 -0800
Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-16 06:20 -0800
Re: linking precedence rules Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 05:10 -0800
Re: linking precedence rules Manfred <noname@invalid.add> - 2017-02-04 17:12 +0100
Re: linking precedence rules Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 20:47 -0800
Re: linking precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-12 13:31 +0000
Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-13 01:58 -0800
Re: linking precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-13 10:41 +0000
Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-14 03:49 -0800
Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-14 12:03 +0000
Re: linking precedence rules David Brown <david.brown@hesbynett.no> - 2017-01-14 14:02 +0100
Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-14 13:46 +0000
Re: linking precedence rules gazelle@shell.xmission.com (Kenny McCormack) - 2017-01-14 14:23 +0000
Re: linking precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 14:31 +0000
Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-14 16:18 +0000
Re: linking precedence rules David Brown <david.brown@hesbynett.no> - 2017-01-14 17:49 +0100
Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-14 17:21 +0000
Re: linking precedence rules Ian Collins <ian-news@hotmail.com> - 2017-01-15 10:12 +1300
Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-14 21:59 +0000
Re: linking precedence rules supercat@casperkitty.com - 2017-01-14 14:12 -0800
Re: linking precedence rules Ian Collins <ian-news@hotmail.com> - 2017-01-15 11:39 +1300
Re: linking precedence rules Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-14 16:03 -0800
Re: linking precedence rules raltbos@xs4all.nl (Richard Bos) - 2017-01-18 11:51 +0000
Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-15 02:04 -0800
Re: linking precedence rules David Brown <david.brown@hesbynett.no> - 2017-01-14 23:48 +0100
Re: linking precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 20:28 +0000
The Unix way vs. the Windows way (Was: linking precedence rules) gazelle@shell.xmission.com (Kenny McCormack) - 2017-01-14 14:14 +0000
Re: The Unix way vs. the Windows way (Was: linking precedence rules) BartC <bc@freeuk.com> - 2017-01-14 14:29 +0000
Re: The Unix way vs. the Windows way (Was: linking precedence rules) supercat@casperkitty.com - 2017-01-14 14:20 -0800
Re: linking precedence rules Michael Holiday <Mike@example.invalid> - 2017-01-15 01:40 -0800
Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-15 11:43 +0000
Re: linking precedence rules antispam@math.uni.wroc.pl - 2017-01-18 19:55 +0000
Re: linking precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 14:22 +0000
Re: comparison logic Noob <root@127.0.0.1> - 2017-01-13 16:05 +0100
Re: comparison logic Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 15:37 +0000
Re: comparison logic Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-13 16:06 +0000
Re: comparison logic Noob <root@127.0.0.1> - 2017-01-13 19:37 +0100
Re: comparison logic BartC <bc@freeuk.com> - 2017-01-13 18:42 +0000
Re: comparison logic Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 18:49 +0000
Re: comparison logic Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-13 20:50 +0000
Re: comparison logic Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 01:05 -0800
Re: comparison logic Michael Holiday <Mike@example.invalid> - 2017-01-14 01:27 -0800
Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-01-14 13:56 -0800
Re: comparison logic Richard Heathfield <rjh@cpax.org.uk> - 2017-01-15 14:45 +0000
Re: comparison logic Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 20:42 -0800
Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-01-15 21:04 -0800
Re: comparison logic Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 04:47 -0800
Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-01-30 11:40 -0800
Re: comparison logic Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-03 16:42 -0800
Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-02-03 18:45 -0800
Re: comparison logic Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 21:03 -0800
Re: comparison logic supercat@casperkitty.com - 2017-02-09 08:07 -0800
Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-02-09 08:50 -0800
Re: comparison logic supercat@casperkitty.com - 2017-02-09 12:15 -0800
Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-02-09 12:38 -0800
Re: comparison logic supercat@casperkitty.com - 2017-02-09 14:13 -0800
Re: comparison logic Keith Thompson <kst-u@mib.org> - 2017-02-09 14:45 -0800
Re: comparison logic Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-12 10:20 -0800
Re: linking precedence rules BartC <bc@freeuk.com> - 2017-01-12 14:32 +0000
Re: linking precedence rules James Kuyper <jameskuyper@verizon.net> - 2017-01-12 13:33 -0500
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-03 18:45 -0800 |
| Subject | Re: comparison logic |
| Message-ID | <ln4m0a4qtn.fsf@kst-u.example.com> |
| In reply to | #103103 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> For example, it
>> would apply to a const-qualified object, which isn't something
>> I'd refer to as a "variable".
>
> Whether you would say so or not, such usage is in common parlance
> and widely understood. What is in the Standard doesn't change the
> meaning of ordinary English, even if the meanings in question
> apply only in technical dialect.
Really? I wouldn't use the word "variable" to refer to something that
can't vary. (Yes, I know the old joke that "constants aren't, variables
won't".)
But I think this stopped being worthwhile several messages ago.
--
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"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-08 21:03 -0800 |
| Subject | Re: comparison logic |
| Message-ID | <kfno9yc6jnf.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #103117 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> writes: > > [...] > >>> For example, it >>> would apply to a const-qualified object, which isn't something >>> I'd refer to as a "variable". >> >> Whether you would say so or not, such usage is in common parlance >> and widely understood. What is in the Standard doesn't change the >> meaning of ordinary English, even if the meanings in question >> apply only in technical dialect. > > Really? I wouldn't use the word "variable" to refer to something that > can't vary. [...] Yes, I thought that was basically what you meant with your earlier statement. But other people do, and an even larger set wouldn't mind the usage even if it isn't one they would use themselves. > But I think this stopped being worthwhile several messages ago. Any time you feel a thread has stopped being worthwhile I hope you will feel free not to respond further, or to reply briefly with your intent not to participate further, as you may think appropriate in each individual circumstance.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-09 08:07 -0800 |
| Subject | Re: comparison logic |
| Message-ID | <bd6404d9-449e-40cf-a15b-50045ce4c5ad@googlegroups.com> |
| In reply to | #103507 |
On Wednesday, February 8, 2017 at 11:03:09 PM UTC-6, Tim Rentsch wrote:
> Keith Thompson writes:
> > Tim Rentsch writes:
> >> Whether you would say so or not, such usage is in common parlance
> >> and widely understood. What is in the Standard doesn't change the
> >> meaning of ordinary English, even if the meanings in question
> >> apply only in technical dialect.
> >
> > Really? I wouldn't use the word "variable" to refer to something that
> > can't vary. [...]
>
> Yes, I thought that was basically what you meant with your
> earlier statement. But other people do, and an even larger
> set wouldn't mind the usage even if it isn't one they would
> use themselves.
I would values a piece of code might use as falling into five categories,
relative to any piece of code that might want to use them:
1. Constants whose values are established at compile time
2. Constants whose values get hard-coded in the executable by the linker.
Different systems have different abilities to accommodate these. For
example, some systems may be able to define a macro such that an
expression like "if (request_size >= HEAP_SIZE) ..." would generate a
compare-with-constant expression even if the value of HEAP_SIZE was
computed by the linker as the total amount of RAM minus a hard-coded
stack allowance and the combined size of all static allocations and
any RAM-resident code.
3. Values which won't be known until runtime, but which once observed
can be expected to hold the same value forevermore.
4. Values which the piece of code can't change, but which might or might
not be able to change via other means.
5. Values which the piece of code can change.
I would say that #1-#2 are not "variables"; if a language can distinguish
between #3 and #4, it may be useful to use a term other than "variables"
for #3. I would suggest that #4 should be called "variables" whether or
not any means *actually* exists via which they can change, if code has to
treat them as though they might.
Many languages do a poor job of distinguishing #3 and #4, even though the
distinction is extremely important from the standpoint of making code be
both efficient and correct.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-09 08:50 -0800 |
| Subject | Re: comparison logic |
| Message-ID | <lna89vz4u5.fsf@kst-u.example.com> |
| In reply to | #103525 |
supercat@casperkitty.com writes:
[...]
> I would values a piece of code might use as falling into five categories,
> relative to any piece of code that might want to use them:
>
> 1. Constants whose values are established at compile time
> 2. Constants whose values get hard-coded in the executable by the linker.
[...]
> 3. Values which won't be known until runtime, but which once observed
> can be expected to hold the same value forevermore.
> 4. Values which the piece of code can't change, but which might or might
> not be able to change via other means.
> 5. Values which the piece of code can change.
>
> I would say that #1-#2 are not "variables"; if a language can distinguish
> between #3 and #4, it may be useful to use a term other than "variables"
> for #3. I would suggest that #4 should be called "variables" whether or
> not any means *actually* exists via which they can change, if code has to
> treat them as though they might.
I suggest that this kind of thing is exactly why the standard avoids
using the word "variable".
--
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"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-09 12:15 -0800 |
| Subject | Re: comparison logic |
| Message-ID | <34105916-ecb3-4dbd-9ad9-e70158cf8715@googlegroups.com> |
| In reply to | #103529 |
On Thursday, February 9, 2017 at 10:50:14 AM UTC-6, Keith Thompson wrote: > I suggest that this kind of thing is exactly why the standard avoids > using the word "variable". The Standard does not seem to have a term to refer specifically to objects which have associated identifiers and are not contained within other aggregates, but sometimes seems to use the term "object" for that purpose, e.g. in N1570 6.2.4 Storage Duration of Objects repeatedly uses the phrase "an object whose identifier is declared...", which would imply grammatically that all objects have associated identifiers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-09 12:38 -0800 |
| Subject | Re: comparison logic |
| Message-ID | <ln8tpfxfow.fsf@kst-u.example.com> |
| In reply to | #103563 |
supercat@casperkitty.com writes:
> On Thursday, February 9, 2017 at 10:50:14 AM UTC-6, Keith Thompson wrote:
>> I suggest that this kind of thing is exactly why the standard avoids
>> using the word "variable".
>
> The Standard does not seem to have a term to refer specifically to objects
> which have associated identifiers and are not contained within other
> aggregates, but sometimes seems to use the term "object" for that purpose,
> e.g. in N1570 6.2.4 Storage Duration of Objects repeatedly uses the phrase
> "an object whose identifier is declared...", which would imply grammatically
> that all objects have associated identifiers.
Fortunately, that doesn't imply that all objects have associated
identifiers, since that would be untrue. Something using the
phrase "an object whose identifier is declared ..." simply does not
apply to any object that does not have an associated identifier.
Just as the phrase "a person whose middle name is Andrew" doesn't
imply that all people have middle names; it simply doesn't apply
either to people who don't have middle names, or to people who have
a middle name other than Andrew.
I suggest that the standard doesn't have a word for that concept because
it doesn't need one.
(I note that the C++ standard does define the word "variable". In a
very quick reading, I wasn't able to determine just what its definition
means.)
I don't hesitate to use the word "variable" in cases where it's
unambiguous. For example given
int n = 42;
I might refer to "the variable n" rather than using the word "object"
which might be unfamiliar to a beginner. But I try to avoid the word in
cases where it might be ambiguous, or where it might lead to a fruitless
discussion like this one.
--
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"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-09 14:13 -0800 |
| Subject | Re: comparison logic |
| Message-ID | <7cc59a2d-cb3b-4ed9-b1a3-68bcd98da74a@googlegroups.com> |
| In reply to | #103567 |
On Thursday, February 9, 2017 at 2:38:45 PM UTC-6, Keith Thompson wrote: > supercat writes: > > The Standard does not seem to have a term to refer specifically to objects > > which have associated identifiers and are not contained within other > > aggregates, but sometimes seems to use the term "object" for that purpose, > > e.g. in N1570 6.2.4 Storage Duration of Objects repeatedly uses the phrase > > "an object whose identifier is declared...", which would imply grammatically > > that all objects have associated identifiers. > > Fortunately, that doesn't imply that all objects have associated > identifiers, since that would be untrue. Something using the > phrase "an object whose identifier is declared ..." simply does not > apply to any object that does not have an associated identifier. > Just as the phrase "a person whose middle name is Andrew" doesn't > imply that all people have middle names; it simply doesn't apply > either to people who don't have middle names, or to people who have > a middle name other than Andrew. Consider the questions: 1. Is Fred's middle name "Quimby"? 2. Does Fred's cat have green eyes? In many countries, everyone has a a middle name containing of zero or more characters. Saying someone doesn't have a middle name is generally equivalent to saying their middle name contains zero characters; if the first question identifies one person named "Fred", and that person's middle name is the empty sequence, the first question would be well-formed and the answer would be "no". The second question, however, would be ill-formed if Fred is not associated with one cat. If the person asking the question wanted the question to be treated as well-formed but answered negatively if Fred doesn't have a cat, the question should be asked "Does Fred have a cat with green eyes?".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-09 14:45 -0800 |
| Subject | Re: comparison logic |
| Message-ID | <lnzihvvv9t.fsf@kst-u.example.com> |
| In reply to | #103574 |
supercat@casperkitty.com writes:
> On Thursday, February 9, 2017 at 2:38:45 PM UTC-6, Keith Thompson wrote:
>> supercat writes:
>> > The Standard does not seem to have a term to refer specifically to objects
>> > which have associated identifiers and are not contained within other
>> > aggregates, but sometimes seems to use the term "object" for that purpose,
>> > e.g. in N1570 6.2.4 Storage Duration of Objects repeatedly uses the phrase
>> > "an object whose identifier is declared...", which would imply grammatically
>> > that all objects have associated identifiers.
>>
>> Fortunately, that doesn't imply that all objects have associated
>> identifiers, since that would be untrue. Something using the
>> phrase "an object whose identifier is declared ..." simply does not
>> apply to any object that does not have an associated identifier.
>> Just as the phrase "a person whose middle name is Andrew" doesn't
>> imply that all people have middle names; it simply doesn't apply
>> either to people who don't have middle names, or to people who have
>> a middle name other than Andrew.
>
> Consider the questions:
>
> 1. Is Fred's middle name "Quimby"?
> 2. Does Fred's cat have green eyes?
>
> In many countries, everyone has a a middle name containing of zero or more
> characters. Saying someone doesn't have a middle name is generally
> equivalent to saying their middle name contains zero characters; if the
> first question identifies one person named "Fred", and that person's middle
> name is the empty sequence, the first question would be well-formed and the
> answer would be "no".
I am aware of no such countries, but even if they exist, my remarks
about middle names were predicated on the assumption that it's possible
not to have a middle name.
> The second question, however, would be ill-formed if Fred is not associated
> with one cat. If the person asking the question wanted the question to
> be treated as well-formed but answered negatively if Fred doesn't have a
> cat, the question should be asked "Does Fred have a cat with green eyes?".
Or, on the other hand, you could just apply some common sense.
Not all objects have associated identifiers, and that statement in the
standard clearly was not intended to imply, and IMNSO does not imply,
that they do.
--
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"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-12 10:20 -0800 |
| Subject | Re: comparison logic |
| Message-ID | <kfnbmu72rvx.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #103525 |
supercat@casperkitty.com writes: > On Wednesday, February 8, 2017 at 11:03:09 PM UTC-6, Tim Rentsch wrote: >> Keith Thompson writes: >>> Tim Rentsch writes: >>>> Whether you would say so or not, such usage is in common parlance >>>> and widely understood. What is in the Standard doesn't change the >>>> meaning of ordinary English, even if the meanings in question >>>> apply only in technical dialect. >>> >>> Really? I wouldn't use the word "variable" to refer to something that >>> can't vary. [...] >> >> Yes, I thought that was basically what you meant with your >> earlier statement. But other people do, and an even larger >> set wouldn't mind the usage even if it isn't one they would >> use themselves. > > I would values a piece of code might use as falling into five categories, > relative to any piece of code that might want to use them: > > 1. Constants whose values are established at compile time > > 2. Constants whose values get hard-coded in the executable by the linker. > Different systems have different abilities to accommodate these. For > example, some systems may be able to define a macro such that an > expression like "if (request_size >= HEAP_SIZE) ..." would generate a > compare-with-constant expression even if the value of HEAP_SIZE was > computed by the linker as the total amount of RAM minus a hard-coded > stack allowance and the combined size of all static allocations and > any RAM-resident code. > > 3. Values which won't be known until runtime, but which once observed > can be expected to hold the same value forevermore. > > 4. Values which the piece of code can't change, but which might or might > not be able to change via other means. > > 5. Values which the piece of code can change. > > I would say that #1-#2 are not "variables"; [...] Yes, different people use the word "variable" in different ways. My point is that lots of people use the word "variable" for any identifier that corresponds to an object in C, including all the cases above.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-12 14:32 +0000 |
| Message-ID | <o583v9$rk1$1@dont-email.me> |
| In reply to | #101515 |
On 12/01/2017 12:13, Michael Holiday wrote: > On 1/8/2017 3:38 PM, Barry Schwarz wrote: >> On Sun, 8 Jan 2017 01:32:44 -0800, Michael Holiday >> <Mike@example.invalid> wrote: >> >>> On 1/8/2017 12:20 AM, Ian Collins wrote: >>>> On 01/ 8/17 08:49 PM, Michael Holiday wrote: >>>>> I return to c.l.c with a closer focus on my c-compiling and linking >>>>> woes, and would like to state my 2 questions as follows: >>>>> >>>>> Q1) How does one see the results of the preprocessor? >>>> >>>> The most common compiler option for this is -E. >>> >>> Ok. Thx. That will allow me to know whether execution has gone through a >>> given path. >> >> The preprocessor has nothing to do with execution paths >> > > whether parsing has been performed. If I write the standard "hello > world" program, how do I figure out which stdio.h is being used from the > compiler's perspective? Try -v option if using gcc (verbose mode). That displays a pile of junk amongst which might be the include search paths used. Alternatively (still assuming gcc): * Start with Hello World program * Make sure it compiles normally * Now hide the include path (eg. on I mine I rename c:\tdm\x....\include to ...\includex) * Check that gcc fails to find stdio.h * Create a new include path of your choice (eg. c:\newincl) * Copy stdio.h (from the renamed path) to c:newincl * Run gcc using: gcc -Ic:\newincl hello.c * It should find stdio.h from the new location, but then complain about some nested includes (as you only copied the one file). Now you have some control over what is being included and without it quietly switching back to its own default paths when a header isn't found. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-12 13:33 -0500 |
| Message-ID | <o58i3h$jev$1@dont-email.me> |
| In reply to | #101515 |
On 01/12/2017 07:13 AM, Michael Holiday wrote: > On 1/8/2017 3:38 PM, Barry Schwarz wrote: >> On Sun, 8 Jan 2017 01:32:44 -0800, Michael Holiday >> <Mike@example.invalid> wrote: >> >>> On 1/8/2017 12:20 AM, Ian Collins wrote: >>>> On 01/ 8/17 08:49 PM, Michael Holiday wrote: >>>>> I return to c.l.c with a closer focus on my c-compiling and linking >>>>> woes, and would like to state my 2 questions as follows: >>>>> >>>>> Q1) How does one see the results of the preprocessor? >>>> >>>> The most common compiler option for this is -E. >>> >>> Ok. Thx. That will allow me to know whether execution has gone through a >>> given path. >> >> The preprocessor has nothing to do with execution paths >> > > whether parsing has been performed. If I write the standard "hello > world" program, how do I figure out which stdio.h is being used from the > compiler's perspective? That's compiler specific. I've found the -E option which is supported by many of the compilers I've used to be helpful. It shows what source file looks like after preprocessing, except that it contains a lot of #line directives. Those directives tell you precisely where the line in your preprocessed program came from - in particular, they can tell you which directory it #included stdio.h from.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web