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 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#99992

David Brown <david.brown@hesbynett.no> writes:
[...]
> You can put things like brackets in macro definitions, but it is usually
> regarded as a /really/ bad idea.

(I presume that by "brackets" you mean {curly braces}.)

Why is it a bad idea?  I've seen (and written) plenty of macro
definitions like:

    #define FOO do { /* blah blah */ } while(0)

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

#100004

On 21/12/16 17:52, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> You can put things like brackets in macro definitions, but it is usually
>> regarded as a /really/ bad idea.
>
> (I presume that by "brackets" you mean {curly braces}.)
>
> Why is it a bad idea?  I've seen (and written) plenty of macro
> definitions like:
>
>     #define FOO do { /* blah blah */ } while(0)
>

Sorry - I understood the point being macros that had /unmatched/ braces. 
  Otherwise there would be no problem with macros when counting braces, 
as the macro invocations would all cancel themselves out.

So I meant it was usually a bad idea to have /unmatched/ braces in macros.

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

#100023

On 21/12/16 20:16, David Brown wrote:
> On 21/12/16 17:52, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> You can put things like brackets in macro definitions, but it is usually
>>> regarded as a /really/ bad idea.
>>
>> (I presume that by "brackets" you mean {curly braces}.)

Yes, I meant curly braces here.  However, my corrected point applies to
round parentheses and square brackets too - I think it is usually a bad
idea for a macro to have unmatched bracketing of any kind.

(And I say "usually" intentionally - there are exceptions.)

>>
>> Why is it a bad idea?  I've seen (and written) plenty of macro
>> definitions like:
>>
>>     #define FOO do { /* blah blah */ } while(0)
>>
> 
> Sorry - I understood the point being macros that had /unmatched/ braces.
>  Otherwise there would be no problem with macros when counting braces,
> as the macro invocations would all cancel themselves out.
> 
> So I meant it was usually a bad idea to have /unmatched/ braces in macros.
> 
> 

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

#99913

DFS <nospam@dfs.com> writes:

> On 12/19/2016 08:59 PM, Richard Heathfield wrote:
>> On 20/12/16 01: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.
>>
>> This is actually quite a tricky problem for a compiler. But it's
>> relatively easy for an editor.
>
>
> Counting open and close {} brackets is of course very easy for a
> compiler.  A count mismatch would generate an error.
>
> Pointing out where the mismatch occurs is more difficult, as you say,
> but I just had an epiphany.  I'm gonna try to code it right now.
>
> It seems kind of easy in my mind.  Which means it will probably turn
> out to be a mess.

Yup!  You have to get the lexing right:

/* /* { ignore */
// and the next\
{

which varies by language standard:

  {a//*}*//b}

Then there are

void f() <%  ??>

to contend with, and if that were not enough there's the prepossessor:

#define OPEN {

int main(void) OPEN }

<snip>
-- 
Ben.

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

#99925

On 20/12/2016 17:04, Ben Bacarisse wrote:
> DFS <nospam@dfs.com> writes:
>
>> On 12/19/2016 08:59 PM, Richard Heathfield wrote:
>>> On 20/12/16 01: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.
>>>
>>> This is actually quite a tricky problem for a compiler. But it's
>>> relatively easy for an editor.
>>
>>
>> Counting open and close {} brackets is of course very easy for a
>> compiler.  A count mismatch would generate an error.
>>
>> Pointing out where the mismatch occurs is more difficult, as you say,
>> but I just had an epiphany.  I'm gonna try to code it right now.
>>
>> It seems kind of easy in my mind.  Which means it will probably turn
>> out to be a mess.
>
> Yup!  You have to get the lexing right:
>
> /* /* { ignore */
> // and the next\
> {
>
> which varies by language standard:
>
>   {a//*}*//b}
>
> Then there are
>
> void f() <%  ??>
>
> to contend with, and if that were not enough there's the prepossessor:
>
> #define OPEN {
>
> int main(void) OPEN }

You make the problems sound insurmountable (and you left out conditional 
code!).

But I think a useful brace matching routine can be written, although it 
might not find all mismatches or it can come up with false positives. 
(It won't good enough to go into gcc but it could helped the OP track 
down their error.)

If people use OPEN for {, then they will use CLOSE for }. And you don't 
worry about that (as it's their lookout)!

I doubt you're going to come across trigraphs, if that's what the <% ??> 
example means (and again, there will be a trigraph for the other brace).

And unbalanced { or } within a comment are going to be rare. (They're 
more likely to come up in lexing code funnily enough:

   if (c == '{')  // now look for }

)

That leaves unbalanced { and } within string literals and perhaps within 
#define like your example. But strings and #defines are easy to identify.

-- 
Bartc

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

#99939

BartC <bc@freeuk.com> writes:

> On 20/12/2016 17:04, Ben Bacarisse wrote:
<snip>
>> ...  You have to get the lexing right:
>>
>> /* /* { ignore */
>> // and the next\
>> {
>>
>> which varies by language standard:
>>
>>   {a//*}*//b}
>>
>> Then there are
>>
>> void f() <%  ??>
>>
>> to contend with, and if that were not enough there's the [preprocessor]:
>>
>> #define OPEN {
>>
>> int main(void) OPEN }
>
> You make the problems sound insurmountable (and you left out
> conditional code!).

I was only getting started!

I didn't want to make it sound insurmountable -- I wanted to make it
sound interesting, and to encourage some simplification.  Emacs's C mode
gets confused by most of these things and it doesn't bother me a bit.
In fact, I use it as a sign that I should redesign.

<snip>
> I doubt you're going to come across trigraphs, if that's what the <%
> ??> example means (and again, there will be a trigraph for the other
> brace).

The <% and %> are not trigraphs but alternative spellings.  You can
write if (x) <% ... %> but puts("<%%>") will not print {}.  In contrast,
puts("??<??>") must print {}.

> And unbalanced { or } within a comment are going to be rare. (They're
> more likely to come up in lexing code funnily enough:
>
>   if (c == '{')  // now look for }

Yes.  I used to set a simplified version of this as an exercise and the
final test case was all the students' programs.

> That leaves unbalanced { and } within string literals and perhaps
> within #define like your example. But strings and #defines are easy to
> identify.

Strings are not always obvious:

#define S(a,b) #a#b
...
puts(S(},{));

(I once had to write a lot of test cases for a C compiler.)

-- 
Ben.

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

#99926

On 12/20/2016 12:04 PM, Ben Bacarisse wrote:
> DFS <nospam@dfs.com> writes:
>
>> On 12/19/2016 08:59 PM, Richard Heathfield wrote:
>>> On 20/12/16 01: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.
>>>
>>> This is actually quite a tricky problem for a compiler. But it's
>>> relatively easy for an editor.
>>
>>
>> Counting open and close {} brackets is of course very easy for a
>> compiler.  A count mismatch would generate an error.
>>
>> Pointing out where the mismatch occurs is more difficult, as you say,
>> but I just had an epiphany.  I'm gonna try to code it right now.
>>
>> It seems kind of easy in my mind.  Which means it will probably turn
>> out to be a mess.
>
> Yup!  You have to get the lexing right:
>
> /* /* { ignore */
> // and the next\
> {
>
> which varies by language standard:
>
>   {a//*}*//b}
>
> Then there are
>
> void f() <%  ??>

For now I'm only worried about curly brackets, since in my limited 
experience a mismatch in them throws a lot of errors/warnings.


> to contend with, and if that were not enough there's the prepossessor:

Is 'prepossessor' a joke or geek slang?




> #define OPEN {
>
> int main(void) OPEN }
>
> <snip>

This one's easy: delete or ignore the #define line and replace ' OPEN ' 
with an opening curly bracket every time it's found.  When I say delete 
I don't mean alter the source of course.

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

#99929

On 20/12/16 18:52, DFS wrote:
> On 12/20/2016 12:04 PM, Ben Bacarisse wrote:
>> DFS <nospam@dfs.com> writes:
>>
>>> On 12/19/2016 08:59 PM, Richard Heathfield wrote:
>>>> On 20/12/16 01: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.
>>>>
>>>> This is actually quite a tricky problem for a compiler. But it's
>>>> relatively easy for an editor.
>>>
>>>
>>> Counting open and close {} brackets is of course very easy for a
>>> compiler.  A count mismatch would generate an error.
>>>
>>> Pointing out where the mismatch occurs is more difficult, as you say,
>>> but I just had an epiphany.  I'm gonna try to code it right now.
>>>
>>> It seems kind of easy in my mind.  Which means it will probably turn
>>> out to be a mess.
>>
>> Yup!  You have to get the lexing right:
>>
>> /* /* { ignore */
>> // and the next\
>> {
>>
>> which varies by language standard:
>>
>>   {a//*}*//b}
>>
>> Then there are
>>
>> void f() <%  ??>
>
> For now I'm only worried about curly brackets,

That's precisely what he's talking about.

Do you count braces inside comments, as he illustrates?

And don't forget that <% is a punctuator that has the same semantics as 
{ or that ??> is a trigraph that has the same semantics as }


> since in my limited
> experience a mismatch in them throws a lot of errors/warnings.

Is there a mismatch in this code?

int main(int argc, char **argv)
{
   if(argc > 1)
   <%
     printf("Hello, world!\n");
   }
   return 0;
}

>
>> to contend with, and if that were not enough there's the prepossessor:
>
> Is 'prepossessor' a joke or geek slang?

Probably a typo.

>> #define OPEN {
>>
>> int main(void) OPEN }
>>
>> <snip>
>
> This one's easy: delete or ignore the #define line and replace ' OPEN '
> with an opening curly bracket every time it's found.  When I say delete
> I don't mean alter the source of course.

Okay, so now your simple brace-checker includes its own rudimentary 
pre-processor. Not quite so simple after all, is it?

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

#99930

On 20/12/2016 18:52, DFS wrote:
> On 12/20/2016 12:04 PM, Ben Bacarisse wrote:

>> #define OPEN {
>>
>> int main(void) OPEN }
>>
>> <snip>
>
> This one's easy: delete or ignore the #define line and replace ' OPEN '
> with an opening curly bracket every time it's found.  When I say delete
> I don't mean alter the source of course.

It's a bit harder than that. OPEN could result from expanding another macro.

Or there could be 100 macros all defined as {, or that include { in 
their definition.

You also now have to scan and look up all identifiers, as well as having 
to actually deal with #define and #undef.

But OPEN could also be defined inside an #include file. Or is part of a 
conditional block so that it might be defined as { or } or anything else 
according to some compiler option.

So you can't deal with it 100% without implementing a full 
pre-processor, and even that might depend on how a compiler is invoked.

-- 
Bartc

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

#99933

BartC <bc@freeuk.com> writes:
> On 20/12/2016 18:52, DFS wrote:
>> On 12/20/2016 12:04 PM, Ben Bacarisse wrote:
>>> #define OPEN {
>>>
>>> int main(void) OPEN }
>>>
>>> <snip>
>>
>> This one's easy: delete or ignore the #define line and replace ' OPEN '
>> with an opening curly bracket every time it's found.  When I say delete
>> I don't mean alter the source of course.
>
> It's a bit harder than that. OPEN could result from expanding another macro.
>
> Or there could be 100 macros all defined as {, or that include { in 
> their definition.
>
> You also now have to scan and look up all identifiers, as well as having 
> to actually deal with #define and #undef.
>
> But OPEN could also be defined inside an #include file. Or is part of a 
> conditional block so that it might be defined as { or } or anything else 
> according to some compiler option.
>
> So you can't deal with it 100% without implementing a full 
> pre-processor, and even that might depend on how a compiler is invoked.

Yes, but dealing with it 99% is probably good enough.

If the code doesn't use macros, digraphs, or trigraphs to hide braces,
existing tools can be used to find any missing braces.  If it does, I
probably don't care about fixing it.

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

#99935

Keith Thompson <kst-u@mib.org> writes:

> If the code doesn't use macros, digraphs, or trigraphs to hide braces,
> existing tools can be used to find any missing braces.  If it does, I
> probably don't care about fixing it.

The only code that I've seen that
a) doesn't (ab)use the features you mention above
b) confuses bracket matchers (emacs, specifically)

#ifdef CAUTIOUS_DOOHICKEY_FROBNICATION
   if(doohickey != NULL && FROBNICATION_DEPTH < 3) {
#else
   if(doohickey != NULL) {
#endif
      /// Refrobnicate the doohickey
      frobnicate(doohickey);
   }

That's not a style I would use, or recommend, but I have worked on
codebases with constructs like that in it, and sometimes so many that
refactoring becomes quite an intrusive change.

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

#99938

Gareth Owen <gwowen@gmail.com> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> If the code doesn't use macros, digraphs, or trigraphs to hide braces,
>> existing tools can be used to find any missing braces.  If it does, I
>> probably don't care about fixing it.
>
> The only code that I've seen that
> a) doesn't (ab)use the features you mention above
> b) confuses bracket matchers (emacs, specifically)
>
> #ifdef CAUTIOUS_DOOHICKEY_FROBNICATION
>    if(doohickey != NULL && FROBNICATION_DEPTH < 3) {
> #else
>    if(doohickey != NULL) {
> #endif
>       /// Refrobnicate the doohickey
>       frobnicate(doohickey);
>    }
>
> That's not a style I would use, or recommend, but I have worked on
> codebases with constructs like that in it, and sometimes so many that
> refactoring becomes quite an intrusive change.

If I felt the need to write code like that, I'd probably put the { on
its own line:

#ifdef CAUTIOUS_DOOHICKEY_FROBNICATION
   if(doohickey != NULL && FROBNICATION_DEPTH < 3)
#else
   if(doohickey != NULL)
#endif
   {
      /// Refrobnicate the doohickey
      frobnicate(doohickey);
   }

I might even consider writing something like this:

   if (doohickey != NULL
#ifdef CAUTIOUS_DOOHICKEY_FROBNICATION
                         && FROBNICATION_DEPTH < 3
#endif
                                                  ) {
      /// Refrobnicate the doohickey
      frobnicate(doohickey);
   }

though I'd be sympathetic to charges that it's too freaking ugly.

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

#100586

Tim Rentsch <txr@alumni.caltech.edu> writes:

> [Snip elegant refactorisations]

Those refactorisations were elegant

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

#100608

Keith Thompson <kst-u@mib.org> writes:

> Gareth Owen <gwowen@gmail.com> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> If the code doesn't use macros, digraphs, or trigraphs to hide braces,
>>> existing tools can be used to find any missing braces.  If it does, I
>>> probably don't care about fixing it.
>>
>> The only code that I've seen that
>> a) doesn't (ab)use the features you mention above
>> b) confuses bracket matchers (emacs, specifically)
>>
>> #ifdef CAUTIOUS_DOOHICKEY_FROBNICATION
>>    if(doohickey != NULL && FROBNICATION_DEPTH < 3) {
>> #else
>>    if(doohickey != NULL) {
>> #endif
>>       /// Refrobnicate the doohickey
>>       frobnicate(doohickey);
>>    }
>>
>> That's not a style I would use, or recommend, but I have worked on
>> codebases with constructs like that in it, and sometimes so many that
>> refactoring becomes quite an intrusive change.
>
> If I felt the need to write code like that, I'd probably put the { on
> its own line:
>
> #ifdef CAUTIOUS_DOOHICKEY_FROBNICATION
>    if(doohickey != NULL && FROBNICATION_DEPTH < 3)
> #else
>    if(doohickey != NULL)
> #endif
>    {
>       /// Refrobnicate the doohickey
>       frobnicate(doohickey);
>    }
>
> I might even consider writing something like this:
>
>    if (doohickey != NULL
> #ifdef CAUTIOUS_DOOHICKEY_FROBNICATION
>                          && FROBNICATION_DEPTH < 3
> #endif
>                                                   ) {
>       /// Refrobnicate the doohickey
>       frobnicate(doohickey);
>    }
>
> though I'd be sympathetic to charges that it's too freaking ugly.

I hope that you wouldn't choose either of those.  Some
alternatives (disclaimer: not compiled) -- this:

    #ifdef CAUTIOUS_DOOHICKEY_FROBNICATION
    #define FROBNICATION_TEST (FROBNICATION_DEPTH < 3)
    #else
    #define FROBNICATION_TEST 1
    #endif
    /* ... */

       if(doohickey != NULL && FROBNICATION_TEST) {


Or this:

    #ifdef CAUTIOUS_DOOHICKEY_FROBNICATION
    #define AND_POSSIBLE_FROB_TEST(e) ((e) && (FROBNICATION_DEPTH < 3))
    #else
    #define AND_POSSIBLE_FROB_TEST(e) (e)
    #endif
    /* ... */

       if(AND_POSSIBLE_FROB_TEST(doohickey != NULL)) {


It's almost always bad to write #if's (or #ifdef's, etc) in open
code, eg, inside function bodies.  Better to add a layer of
abstraction (accomplished here by using a macro, although
there are other possibilities) to keep the function body
clean.  Furthermore, if it happens one place, there's a good
chance it happens or is going to happen somewhere else, in
which case the preprocessor testing should be factored anyway,
and the extra layer of abstraction helps with that.

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

#100622

On 29/12/16 01:36, Tim Rentsch wrote:
> Keith Thompson <kst-u@mib.org> writes:
> 
>> Gareth Owen <gwowen@gmail.com> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> If the code doesn't use macros, digraphs, or trigraphs to hide braces,
>>>> existing tools can be used to find any missing braces.  If it does, I
>>>> probably don't care about fixing it.
>>>
>>> The only code that I've seen that
>>> a) doesn't (ab)use the features you mention above
>>> b) confuses bracket matchers (emacs, specifically)
>>>
>>> #ifdef CAUTIOUS_DOOHICKEY_FROBNICATION
>>>    if(doohickey != NULL && FROBNICATION_DEPTH < 3) {
>>> #else
>>>    if(doohickey != NULL) {
>>> #endif
>>>       /// Refrobnicate the doohickey
>>>       frobnicate(doohickey);
>>>    }
>>>
>>> That's not a style I would use, or recommend, but I have worked on
>>> codebases with constructs like that in it, and sometimes so many that
>>> refactoring becomes quite an intrusive change.
>>
>> If I felt the need to write code like that, I'd probably put the { on
>> its own line:
>>
>> #ifdef CAUTIOUS_DOOHICKEY_FROBNICATION
>>    if(doohickey != NULL && FROBNICATION_DEPTH < 3)
>> #else
>>    if(doohickey != NULL)
>> #endif
>>    {
>>       /// Refrobnicate the doohickey
>>       frobnicate(doohickey);
>>    }
>>
>> I might even consider writing something like this:
>>
>>    if (doohickey != NULL
>> #ifdef CAUTIOUS_DOOHICKEY_FROBNICATION
>>                          && FROBNICATION_DEPTH < 3
>> #endif
>>                                                   ) {
>>       /// Refrobnicate the doohickey
>>       frobnicate(doohickey);
>>    }
>>
>> though I'd be sympathetic to charges that it's too freaking ugly.
> 
> I hope that you wouldn't choose either of those.  Some
> alternatives (disclaimer: not compiled) -- this:
> 
>     #ifdef CAUTIOUS_DOOHICKEY_FROBNICATION
>     #define FROBNICATION_TEST (FROBNICATION_DEPTH < 3)
>     #else
>     #define FROBNICATION_TEST 1
>     #endif
>     /* ... */
> 
>        if(doohickey != NULL && FROBNICATION_TEST) {
> 

That is a possibility, but is it a good thing to put the definition of
FROBNICATION_TEST far from its usage?  With Keith's version, the real
code is clear at that point in the code.

> 
> Or this:
> 
>     #ifdef CAUTIOUS_DOOHICKEY_FROBNICATION
>     #define AND_POSSIBLE_FROB_TEST(e) ((e) && (FROBNICATION_DEPTH < 3))
>     #else
>     #define AND_POSSIBLE_FROB_TEST(e) (e)
>     #endif
>     /* ... */
> 
>        if(AND_POSSIBLE_FROB_TEST(doohickey != NULL)) {
> 
> 
> It's almost always bad to write #if's (or #ifdef's, etc) in open
> code, eg, inside function bodies.  Better to add a layer of
> abstraction (accomplished here by using a macro, although
> there are other possibilities) to keep the function body
> clean.  Furthermore, if it happens one place, there's a good
> chance it happens or is going to happen somewhere else, in
> which case the preprocessor testing should be factored anyway,
> and the extra layer of abstraction helps with that.
> 

There are many ways to write this sort of thing, each with advantages
and disadvantages.  I agree that it is rarely nice to put #if's in the
middle of a function - but I also think it is good to have related code
close together.

Here are another couple of possibilities.  Without a lot more context
(such as whether these tests are used once or several times) it is hard
to rate the different versions, so I am just airing ideas and not
claiming that one is better than an other.

#ifdef CAUTIOUS_DOOHICKEY_FROBNICATION
static bool doohickeyTest(int* doohickey) {
	return (doohickey != NULL && FROBNICATION_DEPTH < 3);
}
#else
static bool doohickeyTest(int* doohickey) {
	return (doohickey != NULL);
}
#endif

...

if (doohickeyTest(doohickey)) {
	frobnicate(doohickey);
}




#ifdef CAUTIOUS_DOOHICKEY_FROBNICATION
#define SKIP_CAUTIOUS_DOOHICKEY_FROBNICATION false
#else
#define SKIP_CAUTIOUS_DOOHICKEY_FROBNICATION true
#endif

if (doohickey != NULL &&
		(SKIP_CAUTIOUS_DOOHICKEY_FROBNICATION ||
			FROBNICATION_DEPTH < 3)) {
	frobnicate(doohickey);
}

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

#99936

On Tuesday, 20 December 2016 20:15:28 UTC, Keith Thompson  wrote:
> BartC <bc@freeuk.com> writes:

> > It's a bit harder than that.
> Yes, but dealing with it 99% is probably good enough.

I said as much in a reply to Ben.

This is about the OP's idea of detecting and expanding macros such as:

  #define OPEN {

You can't deal with this completely without (1) implementing a preprocessor; (2) supplying it with the same command-line macro defs as will be given to the compiler.

-- 
Bartc

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

#99937

On Tuesday, December 20, 2016 at 9:25:39 PM UTC, bart...@gmail.com wrote:
> On Tuesday, 20 December 2016 20:15:28 UTC, Keith Thompson  wrote:
> > BartC <bc@freeuk.com> writes:
> 
> > > It's a bit harder than that.
> > Yes, but dealing with it 99% is probably good enough.
> 
> I said as much in a reply to Ben.
> 
> This is about the OP's idea of detecting and expanding macros such as:
> 
>   #define OPEN {
> 
> You can't deal with this completely without (1) implementing a
> preprocessor; (2) supplying it with the same command-line macro 
> defs as will be given to the compiler.
> 
But you shouldn't need to implement a C pre-processor. It's not
as if you're the only person in the world who has ever had to
pre-process C code. Just take one, hook it up to a simple stack-
based matcher, put in a bit of escape logic for strings and 
comments, and you're done.

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

#99940

On 20/12/2016 21:39, Malcolm McLean wrote:
> On Tuesday, December 20, 2016 at 9:25:39 PM UTC, bart...@gmail.com wrote:
>> On Tuesday, 20 December 2016 20:15:28 UTC, Keith Thompson  wrote:
>>> BartC <bc@freeuk.com> writes:
>>
>>>> It's a bit harder than that.
>>> Yes, but dealing with it 99% is probably good enough.
>>
>> I said as much in a reply to Ben.
>>
>> This is about the OP's idea of detecting and expanding macros such as:
>>
>>   #define OPEN {
>>
>> You can't deal with this completely without (1) implementing a
>> preprocessor; (2) supplying it with the same command-line macro
>> defs as will be given to the compiler.
>>
> But you shouldn't need to implement a C pre-processor. It's not
> as if you're the only person in the world who has ever had to
> pre-process C code. Just take one, hook it up to a simple stack-
> based matcher, put in a bit of escape logic for strings and
> comments, and you're done.

You make it sound so simple!

I think I would find it easier to write a pre-processor than try and 
source, build and interface to someone else's.

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.


-- 
Bartc

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

#99942

On Tuesday, December 20, 2016 at 9:58:44 PM UTC, Bart wrote:
> On 20/12/2016 21:39, Malcolm McLean wrote:
> > On Tuesday, December 20, 2016 at 9:25:39 PM UTC, bart...@gmail.com wrote:
> >> On Tuesday, 20 December 2016 20:15:28 UTC, Keith Thompson  wrote:
> >>> BartC <bc@freeuk.com> writes:
> >>
> >>>> It's a bit harder than that.
> >>> Yes, but dealing with it 99% is probably good enough.
> >>
> >> I said as much in a reply to Ben.
> >>
> >> This is about the OP's idea of detecting and expanding macros such as:
> >>
> >>   #define OPEN {
> >>
> >> You can't deal with this completely without (1) implementing a
> >> preprocessor; (2) supplying it with the same command-line macro
> >> defs as will be given to the compiler.
> >>
> > But you shouldn't need to implement a C pre-processor. It's not
> > as if you're the only person in the world who has ever had to
> > pre-process C code. Just take one, hook it up to a simple stack-
> > based matcher, put in a bit of escape logic for strings and
> > comments, and you're done.
> 
> You make it sound so simple!
> 
> I think I would find it easier to write a pre-processor than try and 
> source, build and interface to someone else's.
> 
> 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.
> 
An important skill is the ability to sniff out competently-written 
modules of software. Pretty much anything authored by me, obviously.
But there are also other people out there who know what they are 
doing. Modules written in pure C89 with no dependencies, and exporting
as few symbols as possible. usually contained in a single source file.

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

#99944

BartC <bc@freeuk.com> writes:

> On 20/12/2016 21:39, Malcolm McLean wrote:
>> On Tuesday, December 20, 2016 at 9:25:39 PM UTC, bart...@gmail.com wrote:
>>> On Tuesday, 20 December 2016 20:15:28 UTC, Keith Thompson  wrote:
>>>> BartC <bc@freeuk.com> writes:
>>>
>>>>> It's a bit harder than that.
>>>> Yes, but dealing with it 99% is probably good enough.
>>>
>>> I said as much in a reply to Ben.
>>>
>>> This is about the OP's idea of detecting and expanding macros such as:
>>>
>>>   #define OPEN {
>>>
>>> You can't deal with this completely without (1) implementing a
>>> preprocessor; (2) supplying it with the same command-line macro
>>> defs as will be given to the compiler.
>>>
>> But you shouldn't need to implement a C pre-processor. It's not
>> as if you're the only person in the world who has ever had to
>> pre-process C code. Just take one, hook it up to a simple stack-
>> based matcher,

A stack is bit over the top.  I'd use a counter.  (Yes, logically it is
a stack-like algorithm.)

>> put in a bit of escape logic for strings and
>> comments, and you're done.

It all depends on what cases you want to ignore.  You can certainly
make it simple if you ignore enough corner cases.

> You make it sound so simple!
>
> I think I would find it easier to write a pre-processor than try and
> source, build and interface to someone else's.
>
> But if the OP is using gcc, they can get preprocessed output out of it
> using gcc -E, and play around with that.

Not just gcc, I hope.  I'd expect every C compiler to have something
similar.

> 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, and the simplest way to be sure of that is to use the -E
flag (or equivalent).

-- 
Ben.

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

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

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

csiph-web