Re: linking precedence rules

From	Manfred <noname@invalid.add>
Newsgroups	comp.lang.c
Subject	Re: linking precedence rules
Date	2017-02-04 17:12 +0100
Organization	Aioe.org NNTP Server
Message-ID	<o74ugl$lf3$1@gioia.aioe.org> (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>

Show all headers | View raw

On 1/15/2017 9:23 AM, Tim Rentsch 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?
>
The way I read it, it is clear to me that the quoted excerpt (i.e. 7.1.2 
p3) only applies to #include directives as per  6.10.2 p2 (i.e. using <>).

An this makes perfectly sense (to me) if considering the rationale of 
6.10.2 p2 and 6.10.2 p3:

- when using <> inclusions the programmer explicitly wants to include 
one of the standard headers provided by the implementation (if it is not 
one of the standard headers, the syntax is meant to be used to #include 
some third-party header as provided by the supplier). In other words, 
the <> syntax is used to #include files as provided by the (supposedly 
trusted) suppliers. Obviously if one of the standard headers (say 
stdio.h) gets replaced with respect to the one provided by the 
implementation, the standard cannot guarantee the behaviour of the 
implementation.

- when using "" inclusions the programmer explicitly wants to the search 
to be extended first to other locations than the standard ones. i.e. the 
programmer is expected to know what he/she is doing, and in this respect 
the standard does not prevent #include "stdio.h" from including 
something else than the standard header (obviously if this happens you 
can't expect the implementation to behave as if #include <stdio.h> was 
written, so you are on your own).
On the other hand, I assume (I didn't check, but I am pretty sure) that 
the standard library uses the <> syntax to include headers, so if you 
write #include "stdio.h" and have stdio.h thus replaced, you may alter 
the behaviour of your own code, not of the library.

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