Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #101963
| From | Michael Holiday <Mike@example.invalid> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: linking precedence rules |
| Date | 2017-01-16 06:20 -0800 |
| Message-ID | <ee434oFi80fU1@mid.individual.net> (permalink) |
| References | (2 earlier) <edef9tF8tn5U1@mid.individual.net> <s8j57c9s06a8iodjk2oovsn409gadcr1ev@4ax.com> <edpa7vFt8c3U1@mid.individual.net> <o57sa7$r5t$1@dont-email.me> <kfnlgucn34k.fsf@x-alumni2.alumni.caltech.edu> |
On 1/15/2017 12:23 AM, Tim Rentsch wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 12/01/17 12:13, Michael Holiday wrote:
>> * The Standard /does/ have something to say about a program
>> supplying a header with the same name as a standard header: "If a
>> file with the same name as one of the above < and > delimited
>> sequences, not provided as part of the implementation, is placed
>> in any of the standard places that are searched for included
>> source files, the behavior is undefined." (So don't do that.)
>
> Here there is a subtlety that deserves amplification. There are
> two different kinds of #include lines, those with <>'s and those
> with ""'s. The first of these is covered by the passage given
> above. For the "" kind of #include line, that causes the line to
> be replaced by a source file, where the file in question (per
> 6.10.2 p3)
>
> is searched for in an implementation-defined manner.
>
> Now here is an interesting question: is the quoted excerpt above
> (ie, 7.1.2 p3) meant to apply only to the places of 6.10.2 p2, or
> is it also meant to apply to "places" (quoted because 6.10.2 p3
> doesn't use the term) of 6.10.2 p3? The use of 'standard places'
> supports the view that it applies only to the 6.10.2 p2 places.
> The use of 'included source files' supports the view that it also
> applies to "places" where 6.10.2 p3 would find source files (note
> though that a header, even a standard header, may be a source
> file, even if it is not necessarily one).
>
> I don't think either of the two positions above is absolutely
> convincing. I lean towards the view that only the places of
> 6.10.2 p2 are the ones that matter, because I think it makes more
> sense: after all, a #include <stdio.h> isn't going to go looking
> in the 6.10.2 p3 "places" anyway, so there is no confusion if one
> of those places has a file named stdio.h. Furthermore it is
> potentially useful to be able to supply a file that augments the
> regular <stdio.h> header in some way, so #include "stdio.h" would
> get that augmentation if it were there, or fall back to <stdio.h>
> if it were not. All upside, no downside - does anyone have a
> different opinion on that assessment?
>
I don't understand you completely, Tim, so I won't edit you. I don't
frankly know if it's fortran or c or ISO where they say the machine
model for the syntax must be fulfilled by a conforming implementation,
which gcc has been on windows ports.
Other parties might remain with their earlier versions of windows until
their environmental variables work. Gosh, how did the washington crew
screw up that one?
You too will have a loved one who is stuck on windows 10, so understand
this as pioneering work. It's a real thing on windoze right now that you
can't change the path in a usual fashion. I downloaded an app for it.
https://www.rapidee.com/en/about
It gave a lot of relevant values with highlighted controls. And after
you look at the data a hundred times, all of a sudden it looks different:
08/25/2016 05:44 PM 1,306 rus1.txt
01/13/2017 10:55 PM 0 SET
12/23/2016 12:39 AM 2,239 solstice1.pl
12/23/2016 12:01 AM 5,331 sunset1.pl
09/19/2016 07:19 PM 4,914 uncles11.txt
12/23/2016 01:46 AM 425,074 Untitled.xcf
07/19/2016 06:35 PM 66,627 Untitled55.png
12/21/2016 07:32 PM <DIR> Visual Studio 2012
12/20/2016 03:14 PM <DIR> Win32-LongPath-master
12/20/2016 03:09 PM 56,283 Win32-LongPath-master.zip
58 File(s) 2,516,409 bytes
19 Dir(s) 36,188,823,552 bytes free
C:\Users\Fred\Documents>del SET
The thing that stood out was the install of visual studio, pretty close
to the time that this loss-of-footing occured. If authorized, it was a
mistake. I think I've identified plenty of sources for my software train
to have gone off-line, but what do you do when an OS puts a preferred
compiling and linking system in your path?
For what it's worth, I worked through C Unleashed using MVC4 and then
upgraded to 6, and never had a bad-linking experience. The terrain is
shiftier for the cross-compiler.
I think this solves where gcc is looking for things now. There have been
significant revisions with the number of compilers getting fewer.
C:\Users\Fred\Documents>gcc -E deque.c >>text1.txt
# 1 "deque.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "deque.c"
# 34 "deque.c"
# 1 "C:/Strawberry/c/x86_64-w64-mingw32/include/string.h" 1 3
# 9 "C:/Strawberry/c/x86_64-w64-mingw32/include/string.h" 3
# 1 "C:/Strawberry/c/x86_64-w64-mingw32/include/crtdefs.h" 1 3
# 10 "C:/Strawberry/c/x86_64-w64-mingw32/include/crtdefs.h" 3
# 1 "C:/Strawberry/c/x86_64-w64-mingw32/include/_mingw.h" 1 3
--
Michael
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web