Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #104092
| From | BartC <bc@freeuk.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Standard Headers |
| Date | 2017-02-17 22:13 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <o87se2$hsg$1@dont-email.me> (permalink) |
| References | <o878ij$840$1@dont-email.me> <87d1egee57.fsf@bsb.me.uk> |
On 17/02/2017 20:49, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> What are the implications (for a normal PC, not embedded devices) of
>> having everything in the standard headers already known to a compiler?
>
> That's fine provided that knowledge is switched on at the right time. A
> call to (for example) printf must be diagnosed as an error if there is
> no declaration in scope but after the magic line #include <stdio.h> the
> compiler must behave as if it contains a declaration of that function.
>
> If you go down the route of having the headers simply trigger the right
> internal behaviour you must Take care with the actual scope. This:
>
> int main(void)
> {
> {
> #include <stdio.h>
> }
> printf("");
> }
> requires a diagnostic.
>
When I took took out the include completely, three compilers out of six
didn't give any diagnostic at all!
Scoped non-function names declared in stdio.h (eg FILE) would cause a
problem, except for macro names (eg EOF) which always have scope to the
end of the file (so EOF after the include is OK, not before).
I don't know if such things are going to be common practice enough to
worry about. Valid code developed elsewhere would have the includes in
the right place. The issue is developing code under such a system which
encourages you to be lax (eg leaving out all such includes) which must
then be put through a normal compiler to pick up those problems.
>> That is, as if every source file was prefixed with #includes for the
>> 20-odd standard C headers.
Well, I don't think anything stops anyone doing that. For the vast
majority of programs, it shouldn't stop them working.
>
> This is not fine for, amongst other reasons, the one given above.
>
>> (And apart from the obvious differences, for example a module with a
>> missing #include compiles OK here, but won't compile elsewhere.)
>
> But is this odd. That obvious difference is very important. Not only
> that, you can declare an int called offsetof provided the macro is not
> defined and you can write double printf = 42; in a conforming program.
I think you can do the latter anyway, provided it's inside a block scope
(with stdio.h included in an outer scope). ('printf' will still be an
identifier in the user namespace; it won't become a keyword.)
>> The question: will a ctype.h with only 14 lines actually work? (It
>> appears to.)
>
> You don't need any lines at all provided that simply seeing the #include
> magically brings the declarations into the scope being processed. Even
> if there really is a file with the 14 declarations in it, you don't even
> need include guards provided the implementation keeps track of what's
> been seen and what has not.
>
> In the long run, because the compiler must behave as if the headers
> contains guarded declarations, it is almost always easier simply to
> write them that way.
Yes, I think I'll have to have header contents defined in a way where
they can come into existence, or be activated, only when the appropriate
standard header is included.
(I haven't decided on a representation yet, except that a production
program will probably have the header info embedded inside.)
--
bartc
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Standard Headers BartC <bc@freeuk.com> - 2017-02-17 16:34 +0000
Re: Standard Headers supercat@casperkitty.com - 2017-02-17 08:50 -0800
Re: Standard Headers luser droog <luser.droog@gmail.com> - 2017-02-17 09:08 -0800
Re: Standard Headers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-17 20:31 +0000
Re: Standard Headers GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-17 18:09 +0100
Re: Standard Headers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-02-17 09:18 -0800
Re: Standard Headers Keith Thompson <kst-u@mib.org> - 2017-02-17 09:26 -0800
Re: Standard Headers BartC <bc@freeuk.com> - 2017-02-17 17:53 +0000
Re: Standard Headers me <crisdunbar@gmail.com> - 2017-02-17 10:23 -0800
Re: Standard Headers BartC <bc@freeuk.com> - 2017-02-17 18:45 +0000
Re: Standard Headers GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-17 19:54 +0100
Re: Standard Headers Keith Thompson <kst-u@mib.org> - 2017-02-17 12:27 -0800
Re: Standard Headers jameskuyper@verizon.net - 2017-02-17 11:38 -0800
Re: Standard Headers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-17 20:49 +0000
Re: Standard Headers supercat@casperkitty.com - 2017-02-17 13:29 -0800
Re: Standard Headers BartC <bc@freeuk.com> - 2017-02-17 22:13 +0000
Re: Standard Headers Nick Bowler <nbowler@draconx.ca> - 2017-02-17 22:28 +0000
Re: Standard Headers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-18 02:48 +0000
Re: Standard Headers supercat@casperkitty.com - 2017-02-18 10:26 -0800
Re: Standard Headers bart4858@gmail.com - 2017-02-18 11:08 -0800
Re: Standard Headers supercat@casperkitty.com - 2017-02-18 11:45 -0800
Re: Standard Headers Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-19 13:45 -0800
Re: Standard Headers BartC <bc@freeuk.com> - 2017-02-19 22:39 +0000
Re: Standard Headers supercat@casperkitty.com - 2017-02-19 16:00 -0800
csiph-web