Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: gcc needs a curly bracket matching/counting function
Date: Tue, 20 Dec 2016 15:51:23 -0800
Organization: None to speak of
Lines: 69
Message-ID: <ln1sx2f9c4.fsf@kst-u.example.com>
References: <o3a201$nfs$1@dont-email.me> <o3a38b$qhp$1@dont-email.me> <o3a8if$1rg$1@dont-email.me> <87zijq5y6s.fsf@bsb.me.uk> <o3buib$o4f$1@dont-email.me> <o3bvs0$tnf$1@dont-email.me> <lnr352fja1.fsf@kst-u.example.com> <cf825321-bbd6-4d15-81f9-64a0a47bd83e@googlegroups.com> <4c33eed2-ece9-4616-b274-e0752353b6c2@googlegroups.com> <o3c9fm$3ns$1@dont-email.me> <lna8bqfd0x.fsf@kst-u.example.com> <o3ceb3$o82$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx02.eternal-september.org; posting-host="e647705ee050c178d8090e6d328af466"; logging-data="5456"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18BzbX9hx8CUnRW3hycBAYb"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:3nsL6GpFMmdwTgrnYSbkZa8JPdY= sha1:xjsK4VCodP9ZPq8UX6by91eAYME=
Xref: csiph.com comp.lang.c:99948

BartC <bc@freeuk.com> writes:
> On 20/12/2016 22:31, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> [...]
>>> I think I would find it easier to write a pre-processor than try and
>>> source, build and interface to someone else's.
>>
>> Seriously??
>>
>>> But if the OP is using gcc, they can get preprocessed output out of it
>>> using gcc -E, and play around with that.
>>>
>>> That wouldn't be a satisfactory solution for me as it would need to be
>>> self-contained, and more efficient. If I run gcc -E on this 2-line program:
>>>
>>> #include <windows.h>
>>> int main(void) {MessageBox(0,"There","Hi",0);}
>>>
>>> I get 82,000 lines of preprocessed output.
>>
>> And how many lines of output would you expect to get from your own
>> preprocessor?  If you don't get 82,000 lines, you're probably doing
>> something wrong.
>
> That's an interesting question. In this case the header file used 
> 'belongs' to a particular C compiler. So with gcc, the outut is 82,000 
> lines; with lccwin, it's 70,000 lines. And both files contain loads of 
> blank lines.
>
> With an independent preprocessor program, the first problem would be to 
> source a suitable set of standard header files (C headers and ones like 
> windows.h). Or, if the source file being analysed is to be compiled by 
> compiler X anyway, I might use the headers for X.

Then you risk getting different results than the user gets from whatever
implementation they're using.

> But I might also decide, for this purpose (analysing braces), not to 
> bother with header files that are enclosed in angle brackets: <stdio.h>.
>
> Or, if they have to be taken account of, I would try and cache the 
> results and/or somehow partition the expanded forms of system headers 
> from user code. Since I know that system headers will be debugged, they 
> don't need checking. I will need to determine the likelihood of they 
> containing macros that could inject unbalanced { or } braces into user code.

Macros defined in standard headers can inject unbalanced braces
indirectly:

    #include <stdint.h>
    #ifdef UINT64_MAX
    {
    #endif

Without processing *all* included headers, preferably the exact same
headers the user is using, you don't have a 100% solution.

> Again, that can be checked once, so that if I see #include <windows.h>, 
> I might be able to remember those results without having to 
> re-preprocess it or re-scan the output.

Unless the header is affected by things defined before it's #included.
<assert.h> is the obvious example.

-- 
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"