Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Problems with lcc-win32 Date: Mon, 06 Mar 2017 08:37:13 -0800 Organization: None to speak of Lines: 87 Message-ID: References: <3cd2645c-a5a1-4284-8fb4-309e14ee4d8e@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: mx02.eternal-september.org; posting-host="249260d50d827d4343a089464177f34d"; logging-data="21294"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19+kWc7jdEtT7f/FICWjSA5" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:xmd747PzpD5ZTXCGeuLbNa0SdoY= sha1:OOPENH6oMKmET9whzuR/SNzsjOM= Xref: csiph.com comp.lang.c:105488 David Brown writes: > On 06/03/17 04:35, Keith Thompson wrote: >> jacob navia writes: >>> Le 05/03/2017 à 23:12, mertesthomas@gmail.com a écrit : >> [...] >>>> 3. A missing include file just triggers a warning. I had to change my test >>>> programs to use something from the include file. This way I can recognize >>>> when an include file is found by the C compiler. >>> >>> Well, that can be fixed easily. Will do next week. Transform the warning >>> in error. But... >>> >>> I am too liberal maybe? People like errors instead of warnings? >>> >>> What if you have an unused include missing? Nothing happens. Now all >>> those builds would crash. Is that better? >>> >>> What do you think? >> [...] >> >> In my opinion a missing include file should be a fatal error. (If it's >> unused, then don't include it.) That's certainly what I'm used to, and >> every compiler I've tried bails out immediately if a header is missing >> (it won't even try to diagnose any following errors). I suspect a lot >> of users would be very surprised to see a missing include diagnosed with >> a non-fatal warning. > > I agree entirely - I find it hard to imagine many use-cases for when a > specified #include file does not exist and yet the compilation can > reasonably continue without it. I would say that when an include file > is missing, the compiler should stop there and then with the error > message - it is most likely to be an error on the part of the user. > > (Of course, it's fine to have a missing include if that directive is > skipped by conditional compilation.) > >> >> Feel free to consider the fact that I'm not an lcc-win user in deciding >> how to deal with this. >> >> On the other hand, some kind of conditional include might be a useful >> extension, perhaps something like: >> >> #include_if_exists >> >> and/or >> >> #if_header_exists >> /* ... */ >> #else >> /* ... */ >> #endif >> > > I can see this second form having some merit, and it would provide more > flexibility than the first suggestion. It would let you write things like: > > #if_header_exists > #include > #define printf super_enhanced_printf > #else > #include > #endif > > However, if someone is going to implement such a feature, then I would > strongly recommend implementing it as "__has_include" : > > #if __has_include() > ... > > Several other compilers, including MSVC, gcc and clang, have this > feature already - it makes sense to use the same syntax for the same > feature. Non-standard extensions should be standardised where possible! > > I didn't know about that. Note that __has_include (along with the related __has_include_next) is implemented in gcc, starting with release 5 I think, but does not appear to be documented either in the gcc manual or in the cpp manual. -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"