Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #99884 > unrolled thread

gcc needs a curly bracket matching/counting function

Back to article view | Back to comp.lang.c

Contents

  gcc needs a curly bracket matching/counting function DFS <nospam@dfs.com> - 2016-12-19 20:38 -0500
    Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 01:59 +0000
      Re: gcc needs a curly bracket matching/counting function DFS <nospam@dfs.com> - 2016-12-19 22:30 -0500
        Re: gcc needs a curly bracket matching/counting function Robert Spanjaard <spamtrap@arumes.com> - 2016-12-20 11:46 +0100
        Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 13:20 +0000
          Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 13:30 +0000
          Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-20 05:35 -0800
            Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-21 12:07 +0100
              Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-21 12:46 +0000
                Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-21 15:10 +0100
                  Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-21 17:10 +0000
                    Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-21 19:50 +0100
                      Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-21 20:15 +0000
                        Re: gcc needs a curly bracket matching/counting function Ike Naar <ike@iceland.freeshell.org> - 2016-12-21 22:36 +0000
                          Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-21 23:46 +0000
                            Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-22 01:54 +0000
                              Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-22 12:16 +0000
                                Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-22 13:06 +0000
                                  Re: gcc needs a curly bracket matching/counting function asetofsymbols@gmail.com - 2016-12-22 05:25 -0800
                                    Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-22 13:34 +0000
                                      Re: gcc needs a curly bracket matching/counting function asetofsymbols@gmail.com - 2016-12-22 08:16 -0800
                                        Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-22 09:30 -0800
                                          Re: gcc needs a curly bracket matching/counting function luser droog <luser.droog@gmail.com> - 2016-12-22 09:40 -0800
                            Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-22 05:33 -0800
                              Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-22 05:41 -0800
                                Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-22 14:53 +0000
                                  Re: gcc needs a curly bracket matching/counting function asetofsymbols@gmail.com - 2016-12-22 08:11 -0800
                                  Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-22 08:27 -0800
                                    Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-22 16:48 +0000
                                      Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-22 09:27 -0800
                                        Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-22 20:12 +0000
                                          Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-22 12:18 -0800
                Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-21 09:04 -0800
                  Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-21 17:24 +0000
                    Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-21 09:41 -0800
                    Re: gcc needs a curly bracket matching/counting function Ian Collins <ian-news@hotmail.com> - 2016-12-22 18:10 +1300
                      Re: gcc needs a curly bracket matching/counting function Ian Collins <ian-news@hotmail.com> - 2016-12-29 14:50 +1300
                        Re: gcc needs a curly bracket matching/counting function Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:07 -0800
                          Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2017-01-02 11:16 +0100
                      Re: gcc needs a curly bracket matching/counting function Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:40 -0800
              Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-21 08:52 -0800
                Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-21 20:16 +0100
                  Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-22 09:41 +0100
        Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-20 17:04 +0000
          Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 18:46 +0000
            Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-20 21:55 +0000
          Re: gcc needs a curly bracket matching/counting function DFS <nospam@dfs.com> - 2016-12-20 13:52 -0500
            Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 19:09 +0000
            Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 19:14 +0000
              Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 12:16 -0800
                Re: gcc needs a curly bracket matching/counting function Gareth Owen <gwowen@gmail.com> - 2016-12-20 20:53 +0000
                  Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 13:51 -0800
                    Re: gcc needs a curly bracket matching/counting function Gareth Owen <gwowen@gmail.com> - 2016-12-29 18:49 +0000
                    Re: gcc needs a curly bracket matching/counting function Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:36 -0800
                      Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-29 12:44 +0100
                Re: gcc needs a curly bracket matching/counting function bart4858@gmail.com - 2016-12-20 13:25 -0800
                  Re: gcc needs a curly bracket matching/counting function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 13:39 -0800
                    Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 21:58 +0000
                      Re: gcc needs a curly bracket matching/counting function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 14:05 -0800
                      Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-20 22:17 +0000
                        Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2017-01-26 19:03 +0000
                      Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 14:31 -0800
                        Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 23:21 +0000
                          Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 15:51 -0800
                            Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-21 00:38 +0000
                        Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2017-01-26 19:11 +0000
      Re: gcc needs a curly bracket matching/counting function mark.bluemel@gmail.com - 2016-12-20 00:50 -0800
    gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-19 18:11 -0800
      Re: gcc needs a curly bracket matching/counting function fir <profesor.fir@gmail.com> - 2016-12-20 03:00 -0800
        Re: gcc needs a curly bracket matching/counting function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 03:50 -0800
          Re: gcc needs a curly bracket matching/counting function fir <profesor.fir@gmail.com> - 2016-12-20 05:20 -0800
      Re: gcc needs a curly bracket matching/counting function DFS <nospam@dfs.com> - 2016-12-20 13:46 -0500
        Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 18:59 +0000
        Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 19:02 +0000
          Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 12:13 -0800
            Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 20:25 +0000
        Re: gcc needs a curly bracket matching/counting function Robert Spanjaard <spamtrap@arumes.com> - 2016-12-20 20:35 +0100
    Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-20 08:56 +0100
    Re: gcc needs a curly bracket matching/counting function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 02:26 -0800
      Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 10:41 +0000
        Re: gcc needs a curly bracket matching/counting function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 02:52 -0800
          Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 11:00 +0000
            Re: gcc needs a curly bracket matching/counting function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 03:19 -0800
              Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 11:31 +0000
              Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-20 17:21 +0000
                Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 17:49 +0000
                  Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-21 12:25 +0100
                  Re: gcc needs a curly bracket matching/counting function Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 01:14 -0800
      Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 09:07 -0800
        Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 17:14 +0000
          Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 09:33 -0800
            Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 17:39 +0000
            Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-20 09:45 -0800
        Re: gcc needs a curly bracket matching/counting function gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-20 17:56 +0000
          Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-20 10:01 -0800
      Re: gcc needs a curly bracket matching/counting function Ian Collins <ian-news@hotmail.com> - 2016-12-21 07:44 +1300
    Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 10:46 +0000
    Re: gcc needs a curly bracket matching/counting function Ike Naar <ike@iceland.freeshell.org> - 2016-12-20 22:00 +0000
      Re: gcc needs a curly bracket matching/counting function Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:39 -0800
    Re: gcc needs a curly bracket matching/counting function Ken Brody <kenbrody@spamcop.net> - 2016-12-22 12:12 -0500
    Re: gcc needs a curly bracket matching/counting function Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-22 12:59 -0700
    Re: gcc needs a curly bracket matching/counting function Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:10 -0800

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#102484

On 20/12/2016 22:17, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:

>> 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.
>
> Other than removing duplicate white space, there not much alternative.
> Your own solution will have to process the same number of lines, even if
> you can avoid the IO round trip.
>
> I don't think duplicating the behaviour of a C pp phase should be
> undertaken lightly.  For one thing you need to implement all the logic
> for finding files which can very from compiler to compiler and even
> version to version (and depend on command line arguments).  Users of the
> tool will expect the tool to duplicate the behaviour of the compiler
> they are using,

They will just point it at the include directory of the main compiler 
they are using. But I've found there is a /lot/ of variation between 
compilers.

With a program containing only "#include <windows.h>", and doing 
preprocessing only, I get (with an experimental cpp):

              #include    Unique      Total scanned
              directives  headers     lines

lccwin        12          11          19,000
Pelles C     380         105         162,000
DMC          255          74         147,000
Tiny C        58          32          27,000
gcc          659         146         340,000

(Preprocessed output is smaller than the final column, presumably 
because a lot of header code is conditional.

I don't know why gcc's headers are at least twice the size of any other 
compiler's, up to nearly 20 times the size, but gcc doesn't seem to like 
doing anything by halves.)

I think if someone just wanted to match curly braces using such a 
preprocessing tool, they might as well choose a more compact set of 
include files!

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#99945

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.

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

[toc] | [prev] | [next] | [standalone]

#99947

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.

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.

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.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

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

[toc] | [prev] | [next] | [standalone]

#99953

On 20/12/2016 23:51, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:

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

I don't think a solution that is guaranted to 100% match a subsequent 
compile is going to be possible. The brace-checking on a module may be 
done with one compiler and a set of include files, then compiled by 
someone else 6 months later on the other side of the world.

But, are there many instances of debugged, distributed source code 
suddenly failing to compile due to brace-mismatching, even though the 
source has not been touched? And due to the use of macros from the 
standard headers?

I bet that up to now, no one had even considered the possibility!

If I had been thinking of a solution for my own use, I'd only be 
interested in my own code and my own headers; that's why I wasn't too 
bothered about standard headers.

BTW how do smart editors managed it: do they scan the tens of thousands 
of lines of include files, and expand all the macros, in order to be 
able to detect unbalanced braces?

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

I was thinking of compile options such as:

   gcc -DABC=1234 program.c

ABC is a macro that might affect how conditional code is compiled.

Then there are things such as __TIME__, which can be different each 
time, although I'm not sure how that would be used to influence 
conditional code. With the use of __LINE__, I can do this:

#if __LINE__ == 10
   #define OPEN {
#else
   #define OPEN }
#endif

Written so that the #if is on line 10, then deleting or inserting any 
line  before that can reverse the definition of OPEN.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#102485

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.

I'm getting 25,000 lines at moment (and gcc's output is up to 94,000 
lines for some reason; maybe one was 32-bit and the other 64-bit or 
something).

But I haven't yet fully validated the output or fixed all the bugs. It's 
possible also that gcc has a specific set of built-in macros that affect 
how conditional code is processed.

(However, I now have the option of using an API to do tasks like the 
OP's; I wouldn't use preprocessed output as a starting point.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#99893

On Tuesday, 20 December 2016 02:00:09 UTC, Richard Heathfield  wrote:

> 
> Emacs has about 37 different ways to do the same thing. Try 
> Control-Meta-Shift-RandomKey, which might work. Or it might bring down a 
> GPS satellite. You never can tell, with Emacs.

I always remap that function to the space bar.

[toc] | [prev] | [next] | [standalone]

#99886

DFS wrote:
> Or is this a function that should be in the editor?

Most editors have that feature (brace matching).

I've had the same problem before.  It's hard to track down by normal
compiler diagnostics.  I don't know of a good way to track that one down.  I've tried commenting out entire functions one by one until
the error stops, but that's a large manual effort.

A compiler should be able to cite mis-matched types in cases like an
"if (..) {" with a "} while (..);", etc.  But in cases of non-flow
brace expressions, it would be more difficult.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#99902

W dniu wtorek, 20 grudnia 2016 03:11:24 UTC+1 użytkownik Rick C. Hodgin napisał:
> DFS wrote:
> > Or is this a function that should be in the editor?
> 
> Most editors have that feature (brace matching).
> 
> I've had the same problem before.  It's hard to track down by normal
> compiler diagnostics.  I don't know of a good way to track that one down.  I've tried commenting out entire functions one by one until
> the error stops, but that's a large manual effort.
> 
> A compiler should be able to cite mis-matched types in cases like an
> "if (..) {" with a "} while (..);", etc.  But in cases of non-flow
> brace expressions, it would be more difficult.
> 
my editor has this matching but it hihglights matched one (one red)
where maybe it would be better to highlight a block (becouse when blocks 
are big they are ofscreen and you dont quite know what ios mathed, with blockhightlighting it could be more visible)

[toc] | [prev] | [next] | [standalone]

#99907

On Tuesday, December 20, 2016 at 11:00:55 AM UTC, fir wrote:
> W dniu wtorek, 20 grudnia 2016 03:11:24 UTC+1 użytkownik Rick C. Hodgin napisał:
> > DFS wrote:
> > > Or is this a function that should be in the editor?
> > 
> > Most editors have that feature (brace matching).
> > 
> > I've had the same problem before.  It's hard to track down by normal
> > compiler diagnostics.  I don't know of a good way to track that one down.  I've tried commenting out entire functions one by one until
> > the error stops, but that's a large manual effort.
> > 
> > A compiler should be able to cite mis-matched types in cases like an
> > "if (..) {" with a "} while (..);", etc.  But in cases of non-flow
> > brace expressions, it would be more difficult.
> > 
> my editor has this matching but it hihglights matched one (one red)
> where maybe it would be better to highlight a block (becouse when blocks 
> are big they are ofscreen and you dont quite know what ios mathed, with 
> blockhightlighting it could be more visible)
>
If you need special software to enable you to understand code, it's
time to take a deep breath, throw the code and the special software
away, and rewrite with a normal editor.

[toc] | [prev] | [next] | [standalone]

#99909

W dniu wtorek, 20 grudnia 2016 12:50:44 UTC+1 użytkownik Malcolm McLean napisał:
> On Tuesday, December 20, 2016 at 11:00:55 AM UTC, fir wrote:
> > W dniu wtorek, 20 grudnia 2016 03:11:24 UTC+1 użytkownik Rick C. Hodgin napisał:
> > > DFS wrote:
> > > > Or is this a function that should be in the editor?
> > > 
> > > Most editors have that feature (brace matching).
> > > 
> > > I've had the same problem before.  It's hard to track down by normal
> > > compiler diagnostics.  I don't know of a good way to track that one down.  I've tried commenting out entire functions one by one until
> > > the error stops, but that's a large manual effort.
> > > 
> > > A compiler should be able to cite mis-matched types in cases like an
> > > "if (..) {" with a "} while (..);", etc.  But in cases of non-flow
> > > brace expressions, it would be more difficult.
> > > 
> > my editor has this matching but it hihglights matched one (one red)
> > where maybe it would be better to highlight a block (becouse when blocks 
> > are big they are ofscreen and you dont quite know what ios mathed, with 
> > blockhightlighting it could be more visible)
> >
> If you need special software to enable you to understand code, it's
> time to take a deep breath, throw the code and the special software
> away, and rewrite with a normal editor.

i understand code but when you do edits you sometimes can mistakenly 
delete one } to much (in some long functions yet within doble for loops yet with if blocks  ) or left one } undeleted
- then compiling this you got cascade of errors, and if you search for
errors this pair-highligting is not as good as block highlighting 
would probably be

[toc] | [prev] | [next] | [standalone]

#99924

On 12/19/2016 09:11 PM, Rick C. Hodgin wrote:
> DFS wrote:
>> Or is this a function that should be in the editor?
>
> Most editors have that feature (brace matching).

The one in geany doesn't do what I'm thinking about.  It always flags 
the very last closing bracket as the mismatched one, when the real 
problem is in the middle somewhere.



> I've had the same problem before.  It's hard to track down by normal
> compiler diagnostics.  I don't know of a good way to track that one down.

I thought I was onto something.

This is a valid set of 14 (seven pairs) of opening and closing curly 
brackets.


{
   {
   }
     {
       {
         {
         }
         {
         }
         {
         }
       }	
     }
}


use O and C for easier visualization (OOCOOOCOCOCCCC)



O
   O
   C
      O
         O
            O
            C
            O
            C
            O
            C
         C
      C
C



Now be the bug and insert an extraneous bracket (Open or Close) anywhere 
in the structure.


O
   O
   C
      O
        X      <--
         O
            O
            C
            O
            C
            O
            C
         C
      C
C


This will probably cause gcc to throw a massive number of errors and 
warnings.

So how do you identify that exact bracket as the problematic one?

Maybe it can be done, but not by me so far.

I tried various algorithms:

* remove the outside OC pairs until you have none, then remove the OC
   pairs starting from the bottom and work up until you're left with one
   OC pair, and the last C is the culprit.

* start at the top and remove all OC pairs in one pass

* attack it differently based on having more Open or more Close
   brackets.

I was always able to break it.

Oh well, it's fun to work on for a while!
	


> I've tried commenting out entire functions one by one until
> the error stops, but that's a large manual effort.


"I spent almost a day going through 4000 lines trying to find the 
missing } in R..."

http://unix.stackexchange.com/questions/10267/how-to-find-unmatched-brackets-in-a-text-file

[toc] | [prev] | [next] | [standalone]

#99927

On 20/12/2016 18:46, DFS wrote:

> This will probably cause gcc to throw a massive number of errors and
> warnings.

With compilers I only look at the first error.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#99928

On 20/12/16 18:46, DFS wrote:
<snip>
>
> This is a valid set of 14 (seven pairs) of opening and closing curly
> brackets.
>
>
> {
>   {
>   }
>     {
>       {
>         {
>         }
>         {
>         }
>         {
>         }
>       }
>     }
> }

That looks wrong. Within the main block there are two sub-blocks, and 
the second sub-block is indented one level too deeply. If you pull that out:

{
   {
   }
   {
     {
       {
       }
       {
       }
       {
       }
     }
   }
}

it's a lot clearer, and a lot easier to spot interlopers.

>
>
> use O and C for easier visualization (OOCOOOCOCOCCCC)

No, thank you.

>
> Now be the bug and insert an extraneous bracket (Open or Close) anywhere
> in the structure.

Okay.

{
   {
   }
   {
     {
       {
       }
       {
       {
       }
       {
       }
     }
   }
}

and it sticks out like a sore thumb, even without any code.

> So how do you identify that exact bracket as the problematic one?

You look. If your indentation is right, it's not a problem. If your 
indentation is wrong, pretty-print it. Then it's right. /Then/ look for 
the wayward brace.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#99932

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 20/12/16 18:46, DFS wrote:
[...]
>> So how do you identify that exact bracket as the problematic one?
>
> You look. If your indentation is right, it's not a problem. If your 
> indentation is wrong, pretty-print it. Then it's right. /Then/ look for 
> the wayward brace.

If there's a missing brace at an intermediate level, pretty-printing
(which typically assumes the braces are correct) can mess things up.
In at least some cases, it's better to assume that the indentation
is correct, and use that to find the missing brace.

If the indentation and braces are both incorrect, you'll just have
to study the code enough to understand its intended structure.

To prevent this, try very hard to keep the indentation and braces
correct as you make incremental changes.

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

[toc] | [prev] | [next] | [standalone]

#99934

On 20/12/16 20:13, Keith Thompson wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> On 20/12/16 18:46, DFS wrote:
> [...]
>>> So how do you identify that exact bracket as the problematic one?
>>
>> You look. If your indentation is right, it's not a problem. If your
>> indentation is wrong, pretty-print it. Then it's right. /Then/ look for
>> the wayward brace.
>
> If there's a missing brace at an intermediate level, pretty-printing
> (which typically assumes the braces are correct) can mess things up.

Yes, I hadn't considered that, mostly because I don't need to do it on 
my own code. When I'm looking at other people's code, generally this 
isn't the problem they're having, so pretty printing works fine. So yes, 
you're quite right.

> In at least some cases, it's better to assume that the indentation
> is correct, and use that to find the missing brace.

It depends just how screwed the indentation is.

In any case, most of the time % will find the problem, as I pointed out 
up-thread.

(With regard to my libellous attack on the Emacs equivalent of %, all I 
can say in my defence is that the lurkers support me in email. No, 
really they do!)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#99931

On 20-12-16 19:46, DFS wrote:
[...]
> Now be the bug and insert an extraneous bracket (Open or Close) anywhere
> in the structure.
>
>
> O
>    O
>    C
>       O
>         X      <--
>          O
>             O
>             C
>             O
>             C
>             O
>             C
>          C
>       C
> C
>
>
> This will probably cause gcc to throw a massive number of errors and
> warnings.
>
> So how do you identify that exact bracket as the problematic one?

As I said: it doesn't have a matching closing bracket with the same indentation.

-- 
Robert Spanjaard

[toc] | [prev] | [next] | [standalone]

#99892

On 20/12/16 02:38, DFS wrote:
> This would potentially help a lot.
> 
> I had ONE extraneous closing curly bracket } in place in a function, and
> gcc -Wall threw 60+ warnings and errors.
> 
> Took me several minutes to find it, and once it was removed I got a 100%
> clean compile
> 
> A simple "error: mismatch in opening and closing curly brackets" would
> be nice.
> 
> 
> {
>  {
>   {
>    {
>     {
>      }
>     }
>    }
>   }
>  }
> }
> 
> 
> Or is this a function that should be in the editor?

A lot of editors not only have syntax highlighting, but have on-the-fly
basic C syntax checking.  A good editor or IDE can save you a lot of
time, and help spot simple mistakes as early possible.  I don't want to
get in an editor war by making recommendations - I will merely recommend
that you look at some large, full-featured IDE's as you main editor.
(It is still a good idea to get used to lighter and simpler editors on
your OS of choice - sometimes these are more convenient.  But most work
can be done within the main editor/IDE.)

[toc] | [prev] | [next] | [standalone]

#99896

On Tuesday, December 20, 2016 at 1:38:38 AM UTC, DFS wrote:
> This would potentially help a lot.
> 
> I had ONE extraneous closing curly bracket } in place in a function, and 
> gcc -Wall threw 60+ warnings and errors.
> 
> Took me several minutes to find it, and once it was removed I got a 100% 
> clean compile
> 
> A simple "error: mismatch in opening and closing curly brackets" would 
> be nice.
> 
> 
> {
>   {
>    {
>     {
>      {
>       }
>      }
>     }
>    }
>   }
> }
> 
> 
> Or is this a function that should be in the editor?
>
Rule of three.

Parentheses may have only three levels of nesting. Use of goto
for error-handling flow control helps. Use i, ii, iii as loop
counter or i, j, k. If you need iv or l (which looks like a 1)
then consider breaking out into a subroutine.

If code isn't human-understandable it is far less valuable.

[toc] | [prev] | [next] | [standalone]

#99897

On 20/12/16 10:26, Malcolm McLean wrote:
> On Tuesday, December 20, 2016 at 1:38:38 AM UTC, DFS wrote:
>> This would potentially help a lot.
>>
>> I had ONE extraneous closing curly bracket } in place in a function, and
>> gcc -Wall threw 60+ warnings and errors.
>>
>> Took me several minutes to find it, and once it was removed I got a 100%
>> clean compile
>>
>> A simple "error: mismatch in opening and closing curly brackets" would
>> be nice.
>>
>>
>> {
>>   {
>>    {
>>     {
>>      {
>>       }
>>      }
>>     }
>>    }
>>   }
>> }
>>
>>
>> Or is this a function that should be in the editor?
>>
> Rule of three.
>
> Parentheses may have only three levels of nesting.

Citation required.

> Use of goto
> for error-handling flow control helps.

Citation required.

> Use i, ii, iii as loop
> counter or i, j, k. If you need iv or l (which looks like a 1)
> then consider breaking out into a subroutine.
>
> If code isn't human-understandable it is far less valuable.

Those two paragraphs contradict each other.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web