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

#99884 — gcc needs a curly bracket matching/counting function

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?

[toc] | [next] | [standalone]

#99885

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.

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

vim/gvim: place the cursor on a brace and press % to move the cursor to 
the matching brace. If there is no match, the editor makes its best 
guess. if your indentation convention is logical (and any of several 
possibilities would qualify), it is then easy to spot which brace is not 
matched.

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.

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

Yes.

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

#99891

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.

If I write a successful, workable routine, do you think the gcc 
maintainers will incorporate it?



>> Took me several minutes to find it, and once it was removed I got a 100%
>> clean compile

short example: one extra closing } in otherwise clean code.

=========================================================================
[dfs@manjaro dev]$ gcc -Wall test.c -o test
test.c:46:1: warning: data definition has no type or storage class
  end = clock();
  ^~~

test.c:46:1: warning: type defaults to ‘int’ in declaration of ‘end’ 
[-Wimplicit-int]

test.c:46:7: error: initializer element is not constant
  end = clock();
        ^~~~~
test.c:47:1: warning: data definition has no type or storage class
  seconds = (double)(end - start)/CLOCKS_PER_SEC;
  ^~~~~~~

test.c:47:1: warning: type defaults to ‘int’ in declaration of ‘seconds’ 
[-Wimplicit-int]

test.c:47:26: error: ‘start’ undeclared here (not in a function)
  seconds = (double)(end - start)/CLOCKS_PER_SEC;
                           ^~~~~
test.c:48:8: error: expected declaration specifiers or ‘...’ before 
string constant
  printf("Run Time: %g seconds\n\n\n", seconds);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

test.c:48:47: error: expected declaration specifiers or ‘...’ before 
‘seconds’
  printf("Run Time: %g seconds\n\n\n", seconds);
                                                ^~~~~~~
test.c:50:1: error: expected identifier or ‘(’ before ‘return’
  return(0);
  ^~~~~~
test.c:52:1: error: expected identifier or ‘(’ before ‘}’ token
  }
  ^
=========================================================================

Definitely confusing and worrying to see that, even though you know not 
all those issues are present.



>> A simple "error: mismatch in opening and closing curly brackets" would
>> be nice.
>
> vim/gvim: place the cursor on a brace and press % to move the cursor to
> the matching brace. If there is no match, the editor makes its best
> guess. if your indentation convention is logical (and any of several
> possibilities would qualify), it is then easy to spot which brace is not
> matched.
 >
> 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.
>
>> Or is this a function that should be in the editor?
>
> Yes.


I'd rather the compiler do at least a quick count for me.



I saw your name on a book: C Unleashed.

Did you get rich off that tome?

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

#99898

On 20-12-16 04:30, DFS wrote:
> 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.

Counting the brackets for a mismatch is easy (don't forget to ignore
brackets in chars, strings and comments though), finding the mismatch in
random code is very hard. However, if you teach yourself to indent your code
in a standard way, you can check if opening and closing brackets with the
same amount of indentation match. In your example, you can see that the
inner most closing bracket is not preceded by an opening bracket with the
same indentation.

-- 
Robert Spanjaard

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

#99910

On 20/12/2016 03:30, DFS wrote:

> I'd rather the compiler do at least a quick count for me.

The compiler is handicapped by the language. This has the right number 
of { and } braces and compiles fine:

     if (a) {
         if (b)
             puts("B1");
             puts("B2");
         }

But when a is 1 and b is 0, it doesn't do what is suggested by the 
indentation. In busy code spanning more lines, and many other sets of { 
and }, it can be hard to spot.

The problem here is that { and } are optional around a single statement.

-- 
Bartc

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

#99911

On 20/12/16 13:20, BartC wrote:
> On 20/12/2016 03:30, DFS wrote:
>
>> I'd rather the compiler do at least a quick count for me.
>
> The compiler is handicapped by the language. This has the right number
> of { and } braces

That's arguable.

> and compiles fine:

Yes. The compiler is under no obligation to enforce best practice. 
That's the programmer's job.

>
>     if (a) {
>         if (b)
>             puts("B1");
>             puts("B2");
>         }
>
> But when a is 1 and b is 0, it doesn't do what is suggested by the
> indentation.

So the indentation is wrong. So don't write it like that.

> In busy code spanning more lines, and many other sets of {
> and }, it can be hard to spot.

All the more reason to use a sensible indentation style.

> The problem here is that { and } are optional around a single statement.

Whether they are optional is optional. You get to choose whether or not 
to write confusing code.

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

#99912

On Tuesday, December 20, 2016 at 8:20:47 AM UTC-5, Bart wrote:
> On 20/12/2016 03:30, DFS wrote:
> 
> > I'd rather the compiler do at least a quick count for me.
> 
> The compiler is handicapped by the language. This has the right number 
> of { and } braces and compiles fine:
> 
>      if (a) {
>          if (b)
>              puts("B1");
>              puts("B2");
>          }

It's also possible that with the macro language things will not align
in raw source code, but only when macros are expanded.  Some editors
can handle this (as David Brown points out), but most can't.

> But when a is 1 and b is 0, it doesn't do what is suggested by the 
> indentation. In busy code spanning more lines, and many other sets of { 
> and }, it can be hard to spot.
> 
> The problem here is that { and } are optional around a single statement.

Something Supercat talks about often is the ability for the compiler to
generate useful diagnostics which can help the developer make better
choices in their development.  He wants it primarily for creating better
optimized code, but I was thinking an extension of that ability might
also work here.

I think most developers write their code in small increments, recompile,
and continue on.  Most compilers today are fast enough that I do this
every few minutes.  It gives me an early cue about where I might've
made a mistake.  I also make all kinds of ongoing little mistakes in
my code that aren't representative of my thought processes, but are
representative of some error in translation from thought to fingers
in typing.  I even type things like >= when I meant > only, etc.  It's
very strange.  I spend so much time tracking down bugs that I know
from my thought processes aren't there.  I have to look at things
line-by-line to find the errors because it was only an error in
typing, and not an error in thinking.  It's so frustrating sometimes.

In any event ... having the ability to generate a type of flow control
map which an editor could coordinate alongside the original source
code would be nice.  The editor could then analyze the code and the
generated map based on things like indentation convention and flag
possible cases where things are weird.  Have them show up in red, or
with another some filterable quantity.

In any event ... I could've used this type of catching several times
in the past.

Best regards,
Rick C. Hodgin

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

#99976

On 20/12/16 14:35, Rick C. Hodgin wrote:
> On Tuesday, December 20, 2016 at 8:20:47 AM UTC-5, Bart wrote:
>> On 20/12/2016 03:30, DFS wrote:
>>
>>> I'd rather the compiler do at least a quick count for me.
>>
>> The compiler is handicapped by the language. This has the right number 
>> of { and } braces and compiles fine:
>>
>>      if (a) {
>>          if (b)
>>              puts("B1");
>>              puts("B2");
>>          }

C gives you the ability to write code in an ugly, confusing and
error-prone manner.  So do all programming languages I have ever seen.
The details of how you can write confusing and bad code with legal
syntax varies from language to language, but it is always possible.

You avoid this particular problem with a simple rule - a for, if or
while statement should always have brackets.  And you need a consistent
bracing and indenting style - I recommend the One True Brace Style as a
starting point, but variations are possible.

> 
> It's also possible that with the macro language things will not align
> in raw source code, but only when macros are expanded.  Some editors
> can handle this (as David Brown points out), but most can't.

You can put things like brackets in macro definitions, but it is usually
regarded as a /really/ bad idea.

> 
>> But when a is 1 and b is 0, it doesn't do what is suggested by the 
>> indentation. In busy code spanning more lines, and many other sets of { 
>> and }, it can be hard to spot.
>>
>> The problem here is that { and } are optional around a single statement.
> 
> Something Supercat talks about often is the ability for the compiler to
> generate useful diagnostics which can help the developer make better
> choices in their development.  He wants it primarily for creating better
> optimized code, but I was thinking an extension of that ability might
> also work here.

One of the nicest new features of gcc 6 (IMHO) is the
"-Wmisleading-indentation" warning.  It will mark code such as Bart's
code above with a warning.  I can't answer for Supercat, but /I/ like
such warnings as they help developers write clear, correct code and help
spot potential errors as soon as possible.

> 
> I think most developers write their code in small increments, recompile,
> and continue on.  Most compilers today are fast enough that I do this
> every few minutes.  It gives me an early cue about where I might've
> made a mistake.  I also make all kinds of ongoing little mistakes in
> my code that aren't representative of my thought processes, but are
> representative of some error in translation from thought to fingers
> in typing.  I even type things like >= when I meant > only, etc.  It's
> very strange.  I spend so much time tracking down bugs that I know
> from my thought processes aren't there.  I have to look at things
> line-by-line to find the errors because it was only an error in
> typing, and not an error in thinking.  It's so frustrating sometimes.

Compilers (and "smart" editors) can be useful for spotting some of these
mistakes.  I compile my code regularly while writing it, even though I
might not be planning on running it on the target for a while.  Compiler
error and warning messages are helpful.

But don't rely on it /too/ much - it's easy to write something that is
perfectly legal, passes all the warning checks, and is still not what
you meant.

> 
> In any event ... having the ability to generate a type of flow control
> map which an editor could coordinate alongside the original source
> code would be nice.  The editor could then analyze the code and the
> generated map based on things like indentation convention and flag
> possible cases where things are weird.  Have them show up in red, or
> with another some filterable quantity.
> 
> In any event ... I could've used this type of catching several times
> in the past.
> 
> Best regards,
> Rick C. Hodgin
> 

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

#99982

On 21/12/2016 11:07, David Brown wrote:
> On 20/12/16 14:35, Rick C. Hodgin wrote:
>> On Tuesday, December 20, 2016 at 8:20:47 AM UTC-5, Bart wrote:
>>> On 20/12/2016 03:30, DFS wrote:
>>>
>>>> I'd rather the compiler do at least a quick count for me.
>>>
>>> The compiler is handicapped by the language. This has the right number
>>> of { and } braces and compiles fine:
>>>
>>>      if (a) {
>>>          if (b)
>>>              puts("B1");
>>>              puts("B2");
>>>          }
>
> C gives you the ability to write code in an ugly, confusing and
> error-prone manner.  So do all programming languages I have ever seen.

In the syntax I normally use, this example is impossible to write 
without invoking an error.

> The details of how you can write confusing and bad code with legal
> syntax varies from language to language, but it is always possible.
>
> You avoid this particular problem with a simple rule - a for, if or
> while statement should always have brackets.

Unfortunately that doesn't always work, as the language won't not cooperate.

If you forget the braces, it won't tell you as it knows nothing about 
your rule, unless it can't match them. You can also put in extra braces, 
and that's OK provided the extra brace is matched elsewhere.

It doesn't help that the same } brace can close an if-block, for-block, 
while-block, do-block, switch-block, function-block, a data-block, and 
just a block-block.

So it's a language design issue; it's not true that all languages are 
the same. Not regarding this block-delimiting anyway.

And people aren't going to follow the rule as it's far too tempting to 
just write:

     if (!fp) return 0;

(leaving this open to brace-matching and dangling else problems).

   And you need a consistent
> bracing and indenting style - I recommend the One True Brace Style as a
> starting point, but variations are possible.

Yes, everyone uses /their own/ consistent style!


-- 
Bartc

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

#99983

On 21/12/16 13:46, BartC wrote:
> On 21/12/2016 11:07, David Brown wrote:
>> On 20/12/16 14:35, Rick C. Hodgin wrote:
>>> On Tuesday, December 20, 2016 at 8:20:47 AM UTC-5, Bart wrote:
>>>> On 20/12/2016 03:30, DFS wrote:
>>>>
>>>>> I'd rather the compiler do at least a quick count for me.
>>>>
>>>> The compiler is handicapped by the language. This has the right number
>>>> of { and } braces and compiles fine:
>>>>
>>>>      if (a) {
>>>>          if (b)
>>>>              puts("B1");
>>>>              puts("B2");
>>>>          }
>>
>> C gives you the ability to write code in an ugly, confusing and
>> error-prone manner.  So do all programming languages I have ever seen.
> 
> In the syntax I normally use, this example is impossible to write
> without invoking an error.

As I said, the details vary from language to language.  But no language
is immune from programmers who write confusing code.  Languages, tools,
coding standards, programmer education and good practice all combine to
reduce the risk of such errors.  For historical reasons, C has a number
of ways to make silly mistakes that many other languages don't have -
this is one of them.  But a decent editor can make this slightly harder
to type (since you get used to indents being generated automatically).
Good tools (gcc 6 spots this, as will many linters and more advanced C
static error checkers).  No coding standard would accept such code.  And
of course if the programmer has been taught properly and is used to
writing code sensibly, then it is very unlikely that they will make such
a mistake.

Mistakes of all sorts /do/ happen, with /all/ programming languages.
Don't pretend that any particular language eliminates typos, bad design,
poor programming habits, or other errors - a  good language design can
greatly reduce the risk of /some/ types programming errors, but that is
all.  And don't confuse weaknesses in a language design with an
inability or unwillingness to use tools to help write correct code.
Just because C /lets/ you write this sort of thing, does not make it any
less /your/ fault if you write it.

Personally, I would have been happier if the C language insisted on
brackets on "if", "while", and "for" statements - it would reduce other
people's mistakes.  (I don't make such mistakes.  I make /other/
mistakes in my coding, but I don't get brackets and indentation wrong.)
 But I can also understand that some people are happy that they are
optional.

> 
>> The details of how you can write confusing and bad code with legal
>> syntax varies from language to language, but it is always possible.
>>
>> You avoid this particular problem with a simple rule - a for, if or
>> while statement should always have brackets.
> 
> Unfortunately that doesn't always work, as the language won't not
> cooperate.

It /always/ works, because the language does not prevent you writing
correct code.

The language does not stop you writing incorrect code, but that's
another matter entirely.

> 
> If you forget the braces, it won't tell you as it knows nothing about
> your rule, unless it can't match them. You can also put in extra braces,
> and that's OK provided the extra brace is matched elsewhere.

It is not the language's job to make sure your code is correct - it is
/your/ job.  And if you can't do it reliably on your own, then it is
/your/ job to make sure you have appropriate tools to help.

> 
> It doesn't help that the same } brace can close an if-block, for-block,
> while-block, do-block, switch-block, function-block, a data-block, and
> just a block-block.

That works just fine.

> 
> So it's a language design issue; it's not true that all languages are
> the same. Not regarding this block-delimiting anyway.

As I said, /all/ languages let you write incorrect or confusing code,
but the details vary.

There are a few things about C that make it easier than necessary to
write incorrect code - this is one of them.  Others include the
automatic fall-through in switch cases, and that "if (x = y)" is legal
code.  But it is still not hard to avoid these potential problems.

> 
> And people aren't going to follow the rule as it's far too tempting to
> just write:
> 
>     if (!fp) return 0;

Many people (including me) see that as fine - /if/ there are no "else"
clauses involved.

> 
> (leaving this open to brace-matching and dangling else problems).
> 
>   And you need a consistent
>> bracing and indenting style - I recommend the One True Brace Style as a
>> starting point, but variations are possible.
> 
> Yes, everyone uses /their own/ consistent style!
> 

You can use existing styles and coding standards, or make your own -
that is up to you.  The point is that having a consistent style is the
key to clear coding her - the details of that style do not matter much.

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

#99994

On 21/12/2016 14:10, David Brown wrote:
> On 21/12/16 13:46, BartC wrote:

> For historical reasons, C has a number
> of ways to make silly mistakes that many other languages don't have -
> this is one of them.

It seems to excel in this.

> It is not the language's job to make sure your code is correct - it is
> /your/ job.  And if you can't do it reliably on your own, then it is
> /your/ job to make sure you have appropriate tools to help.

Why should it be necessary to introduce extra tools to fix deficiencies 
in the language? There are loads of things in C that can lead to 
inadvertent errors that could so easily have been fixed.

This is a small selection, together with whether the design of C allows 
various errors to be detected, compared with one of my languages:

                                        C               X

Use the wrong sort of } brace          Not detected    Detected

Index a pointer that is supposed       Not detected    Detected
to be just a pointer

Use octal 0125 instead of decimal      Not detected    Is decimal

= instead of ==  if (a=b)              Not detected    Less likely

== instead of =  a==b;                 Not detected    Detected

"abc"[1]='X';                          Not detected    Detected

defau1t: instead of default:           Not detected    Can't happen

if (p==NULL); exit(0);                 Not detected    Can't happen

Write 100000 instead of 1000000        Not detectable  Use 1_000_000

Think a<<b+c means (a<<b+c)            Not detected    Means (a<<b+c)

You still think the language bears no responsibility, and it should be 
up to you, or up to extra tools that you are obliged to use?

>> It doesn't help that the same } brace can close an if-block, for-block,
>> while-block, do-block, switch-block, function-block, a data-block, and
>> just a block-block.
>
> That works just fine.

No it doesn't. Suppose you miss out the closing } of a while-block. The 
next } the compiler sees is the one /you/ think closes the function, but 
the compiler assumes closes the while-block. So, with gcc which allows 
nested functions, it might not raise the alarm until 1000 lines later at 
the end of the file.

With a language that insists on different block-endings such as 'end 
while' and 'end function', it is impossible to mix them up without the 
compiler complaining.

Even leaving compilation aside, it will be more obvious to the human 
reader of the code.

(I suppose you will just say use a style such as "} //end while", which 
although it might help a bit, no-one is going to do, and it is not 
checked by the compiler.)

>> So it's a language design issue; it's not true that all languages are
>> the same. Not regarding this block-delimiting anyway.
>
> As I said, /all/ languages let you write incorrect or confusing code,
> but the details vary.
>
> There are a few things about C that make it easier than necessary to
> write incorrect code - this is one of them.  Others include the
> automatic fall-through in switch cases, and that "if (x = y)" is legal
> code.  But it is still not hard to avoid these potential problems.

Well it would have been less hard if the language had done it right in 
the first place! (Algol68, which got block handling correct, came out in 
1968; C was a couple of years later at least, but decided to go with {, 
} and nothing.)

>> And people aren't going to follow the rule as it's far too tempting to
>> just write:
>>
>>     if (!fp) return 0;
>
> Many people (including me) see that as fine - /if/ there are no "else"
> clauses involved.

And if one is added later? It is also common to start with this:

        if (!fp)
           return 0;

and turn it into this:

        if (!fp)
           puts("Can't open file");
           return 0;

especially if most other ifs use braces. If you have rules you need to 
stick to them!

-- 
Bartc

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

#100003

On 21/12/16 18:10, BartC wrote:
> On 21/12/2016 14:10, David Brown wrote:
>> On 21/12/16 13:46, BartC wrote:
>
>> For historical reasons, C has a number
>> of ways to make silly mistakes that many other languages don't have -
>> this is one of them.
>
> It seems to excel in this.
>
>> It is not the language's job to make sure your code is correct - it is
>> /your/ job.  And if you can't do it reliably on your own, then it is
>> /your/ job to make sure you have appropriate tools to help.
>
> Why should it be necessary to introduce extra tools to fix deficiencies
> in the language? There are loads of things in C that can lead to
> inadvertent errors that could so easily have been fixed.

You seem to be confusing C with something else.  C is a language that is 
about 40 years old, based partly on even older languages.  Backwards 
compatibility has always been of critical importance to C, both the 
standards and the implementations.

This means that C has not been able to take advantage of many of the 
ideas of programming language design over the last 4 decades.  It means 
that some aspects of it's design are based on how computers and 
compilers were used at that time - such as relying on extra tools for 
things that might be built into a language designed today.  And it also 
means that /none/ of the problems of C are particularly bad or hard to 
avoid, since it is still around today and for many types of programming 
work it is clearly the best (or only!) choice.

And when you say things "could so easily have been fixed", I presume you 
mean that they could have been fixed 40 years ago - since backwards 
compatibility means few changes can be made now?

>
> This is a small selection, together with whether the design of C allows
> various errors to be detected, compared with one of my languages:
>
>                                        C               X
>
> Use the wrong sort of } brace          Not detected    Detected
>

C only has one type of brace, so there is no problem here.

> Index a pointer that is supposed       Not detected    Detected
> to be just a pointer
>

I have never found that to be a problem.  But then, I understand how 
arrays and pointers work in C.  I would have been happy to see arrays 
being first-class types independent of pointers, but I can understand 
why they are the way they are in C, and I have no problem using them.

> Use octal 0125 instead of decimal      Not detected    Is decimal
>

That's an annoying one.  I would very much like gcc to have a warning on 
the use of octal constants (other than 0, of course).  Support for octal 
cannot be removed from the language, for backward compatibility.

> = instead of ==  if (a=b)              Not detected    Less likely
>

Almost all compilers will spot that one.

> == instead of =  a==b;                 Not detected    Detected
>

Almost all compilers will spot that one.

> "abc"[1]='X';                          Not detected    Detected
>

Almost all compilers will spot that one.

> defau1t: instead of default:           Not detected    Can't happen
>

Compilers can give warnings on missing default, and editors with syntax 
highlighting will make this mistake obvious.  You might also like to buy 
a keyboard where the lower case "l" and the digit "1" are somewhat 
separated, reducing the risk of making this typo to virtually zero.

> if (p==NULL); exit(0);                 Not detected    Can't happen
>

This is avoided by writing correct code.  It is also avoided by having a 
habit of always using brackets on your conditionals.  C does not require 
that - but you are free to do so.

> Write 100000 instead of 1000000        Not detectable  Use 1_000_000
>

I too would like a digit separator.  But I can live without it.

> Think a<<b+c means (a<<b+c)            Not detected    Means (a<<b+c)
>

Writing "a<<b+c" is, IMHO, simply bad coding.  Write either "(a << b) + 
c", or "a << (b + c)" according to what you mean.  It's not hard.

> You still think the language bears no responsibility, and it should be
> up to you, or up to extra tools that you are obliged to use?

If those are the things you find hard, then yes - I think the language 
bears no significant responsibility here.  These "extra tools" are a 
"decent editor" and a "compiler" - both of which are quite important to 
productive C programming.  There are more advanced tools you can buy 
that do more checking, but they are not needed for this level of checking.

>
>>> It doesn't help that the same } brace can close an if-block, for-block,
>>> while-block, do-block, switch-block, function-block, a data-block, and
>>> just a block-block.
>>
>> That works just fine.
>
> No it doesn't. Suppose you miss out the closing } of a while-block. The
> next } the compiler sees is the one /you/ think closes the function, but
> the compiler assumes closes the while-block. So, with gcc which allows
> nested functions, it might not raise the alarm until 1000 lines later at
> the end of the file.
>

A decent editor will help you spot the problem early.  And failing that, 
the compiler will at least see that there is a problem.  So it works 
fine - and it is a lot simpler and easier than having different sorts of 
close brackets for different uses.  I agree that compiler warnings could 
always be better - and I am happy that this is something the gcc 
developers put a great deal of effort into.

> With a language that insists on different block-endings such as 'end
> while' and 'end function', it is impossible to mix them up without the
> compiler complaining.
>
> Even leaving compilation aside, it will be more obvious to the human
> reader of the code.
>

That is only an issue if you fail to indent properly or write functions 
that are too long to be easily comprehended.

> (I suppose you will just say use a style such as "} //end while", which
> although it might help a bit, no-one is going to do, and it is not
> checked by the compiler.)
>

You can use such a style if you like - some people do write that sort of 
thing.  It is common with #ifdef/#endif pairs, since they sometimes span 
large ranges of code.  Similarly, it is common in C++ for class 
declarations, namespaces, etc.  But normal functions should not be so 
long that these sorts of comments are useful.

>>> So it's a language design issue; it's not true that all languages are
>>> the same. Not regarding this block-delimiting anyway.
>>
>> As I said, /all/ languages let you write incorrect or confusing code,
>> but the details vary.
>>
>> There are a few things about C that make it easier than necessary to
>> write incorrect code - this is one of them.  Others include the
>> automatic fall-through in switch cases, and that "if (x = y)" is legal
>> code.  But it is still not hard to avoid these potential problems.
>
> Well it would have been less hard if the language had done it right in
> the first place! (Algol68, which got block handling correct, came out in
> 1968; C was a couple of years later at least, but decided to go with {,
> } and nothing.)
>
>>> And people aren't going to follow the rule as it's far too tempting to
>>> just write:
>>>
>>>     if (!fp) return 0;
>>
>> Many people (including me) see that as fine - /if/ there are no "else"
>> clauses involved.
>
> And if one is added later?

Then you add the brackets when you add a second line.  It's not rocket 
science.

> It is also common to start with this:
>
>        if (!fp)
>           return 0;

I see that as a common bad habit.

>
> and turn it into this:
>
>        if (!fp)
>           puts("Can't open file");
>           return 0;
>

No, it is not common to write such code.  I agree that it is a fairly 
common style to allow a single indented statement on the line after an 
"if", with no brackets.  But when working with that code, if you add 
another statement to the inside of the conditional, you add the braces. 
Sometimes mistakes are made here, but it is not common.

But using a better brace convention means that you /don't/ make such 
mistakes at all.


> especially if most other ifs use braces. If you have rules you need to
> stick to them!
>

Yes, you have to stick to your rules - that's what "consistency" means. 
It does not mean that you have to have the minimum number of rules - 
it's okay to be a little bit smart.

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

#100008

On 21/12/2016 18:50, David Brown wrote:
> On 21/12/16 18:10, BartC wrote:

> You seem to be confusing C with something else.  C is a language that is
> about 40 years old, based partly on even older languages.

I mentioned Algol-68 which is older. That one got braces right.

> Backwards
> compatibility has always been of critical importance to C, both the
> standards and the implementations.
>
> This means that C has not been able to take advantage of many of the
> ideas of programming language design over the last 4 decades.

Unlike Fortran, Ada, C++ and even Pascal which have all evolved? And 
what are the compatibility issues in allowing 1000_000!

>                                        C               X
>>
>> Use the wrong sort of } brace          Not detected    Detected
>>
>
> C only has one type of brace, so there is no problem here.

You losing the opportunity to detect a missing block-end delimiter of 
the right type.

>> = instead of ==  if (a=b)              Not detected    Less likely
>>
>
> Almost all compilers will spot that one.
> Almost all compilers will spot that one.
> Almost all compilers will spot that one.

/Some/ compilers, and with the right set of options.

It's funny how the C Standard usually has the last word in this group. 
But with practical problems like these, the Standard goes out the 
window. Instead we need the right compiler, the right options, the right 
editor, the right analysers, the right Cdecl program, the right 
guidelines...

>> if (p==NULL); exit(0);                 Not detected    Can't happen

> This is avoided by writing correct code.  It is also avoided by having a
> habit of always using brackets on your conditionals.

Like: if (p=NULL); {exit(0);} ?

>> You still think the language bears no responsibility, and it should be
>> up to you, or up to extra tools that you are obliged to use?
>
> If those are the things you find hard, then yes - I think the language
> bears no significant responsibility here.  These "extra tools" are a
> "decent editor" and a "compiler" - both of which are quite important to
> productive C programming.

I wonder what tools were available 40 years ago?

-- 
Bartc

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

#100010

On 2016-12-21, BartC <bc@freeuk.com> wrote:
> On 21/12/2016 18:50, David Brown wrote:
>> On 21/12/16 18:10, BartC wrote:
>
>> You seem to be confusing C with something else.  C is a language that is
>> about 40 years old, based partly on even older languages.
>
> I mentioned Algol-68 which is older. That one got braces right.

Can you elaborate? Where does Algol-68 use braces?

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

#100014

On 21/12/2016 22:36, Ike Naar wrote:
> On 2016-12-21, BartC <bc@freeuk.com> wrote:
>> On 21/12/2016 18:50, David Brown wrote:
>>> On 21/12/16 18:10, BartC wrote:
>>
>>> You seem to be confusing C with something else.  C is a language that is
>>> about 40 years old, based partly on even older languages.
>>
>> I mentioned Algol-68 which is older. That one got braces right.
>
> Can you elaborate? Where does Algol-68 use braces?

I didn't express it well. That language solves the braces problem by 
using a different scheme (that doesn't use braces):

A68: if a;b then c;d;e elif f then g elif h then i;j else k fi

C:   if (a,b) {c;d;e;} else if (f) g; else if (h) {i;j;} else k;

- C needs 3 grouping methods for serially-evaluated elements:
   (), {} and nothing, compared with one (and uses either "," as
   [effective] separator or ";" as terminator).

- C allows single elements to either be inside {} or not, adding
   variability to code (and introducing the problems that have been
   discussed when code subsequently is edited). Elements that are
   conditional expressions must use ().

- C leaves itself open to the dangling else problem

- If C closes an if-statement with }, then it has the problem that
   it can get mixed up with a closing brace from another kind of
   statement (not possible using 'fi' or 'end if').

- There are probably more placement styles for { and } than are
   possible with the A68 scheme; yet more variability in code.

But apart from all that, there's not much in it...

-- 
bartc

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

#100017

BartC <bc@freeuk.com> writes:

> On 21/12/2016 22:36, Ike Naar wrote:
>> On 2016-12-21, BartC <bc@freeuk.com> wrote:
<snip>
>>> I mentioned Algol-68 which is older. That one got braces right.
>>
>> Can you elaborate? Where does Algol-68 use braces?
>
> I didn't express it well. That language solves the braces problem by
> using a different scheme (that doesn't use braces):
>
> A68: if a;b then c;d;e elif f then g elif h then i;j else k fi
>
> C:   if (a,b) {c;d;e;} else if (f) g; else if (h) {i;j;} else k;
<snip>
> - There are probably more placement styles for { and } than are
>   possible with the A68 scheme; yet more variability in code.

I think you are forgetting.  Did you write BEGIN ... END, 'begin'
... 'end' or .BEGIN ... .END?  And you can use (...)  instead of begin
... end, just as there's no need to use 'IF' 'THEN' 'ELSE' either since
you might choose to use ( | and ).  And what were the options for
writing multiplication and so on in your favourite compiler?  And, of
course, then there is white space in identifiers...

Algol 68 has plenty of ways to introduce variability in code.

-- 
Ben.

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

#100026

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

>> A68: if a;b then c;d;e elif f then g elif h then i;j else k fi
>>
>> C:   if (a,b) {c;d;e;} else if (f) g; else if (h) {i;j;} else k;
> <snip>
>> - There are probably more placement styles for { and } than are
>>   possible with the A68 scheme; yet more variability in code.
>
> I think you are forgetting.  Did you write BEGIN ... END, 'begin'
> ... 'end' or .BEGIN ... .END?

I don't remember BEGIN...END in that language. I used them in Algol and 
Pascal and they were just as annoying as {...} in C.

   And you can use (...)  instead of begin
> ... end, just as there's no need to use 'IF' 'THEN' 'ELSE' either since
> you might choose to use ( | and ).  And what were the options for
> writing multiplication and so on in your favourite compiler?  And, of
> course, then there is white space in identifiers...
>
> Algol 68 has plenty of ways to introduce variability in code.

Yes, actual A68 implementations with their various 'stropping' schemes 
resulted in some very ugly source code; it's not surprising it didn't 
catch on. And I didn't care much for the rest of the language.

But I'm actually thinking of my own syntax which is derived from Algol 
68 (just like C's could have been) which doesn't have those issues you 
mentioned. You don't have to literally copy everything including all the 
warts.

(As for the short-forms such as (a|b|c) for 'if-then-else-fi', I only 
allow those in expressions.)

A few years ago I was using a thin wrapper around C source code which 
replaced {,} around statement blocks with 'then', 'do' and so on.

Here are two example functions; although they don't look like it, the 
code is actually C apart from the block delimiters**:

http://pastebin.com/UanK17aH

And this is the translation to actual C; notice the line numbers 
correspond exactly, as it is a line-at-a-time translation:

http://pastebin.com/vQ621sGs

It really doesn't take much to turn C syntax into an Algol-68 lookalike! 
The translator was about 400 lines of code.


(** There were few other things that were different:

* := used in place of =

* = used in place of ==, and <> for !=

* Empty macros such as 'function', 'proc' and 'global' are used

* 'FORD' is a macro for a down-counting A to B for-statement

* The translator also extracted local functions prototypes into a .cl
   file (included in the same module), and global ones into a .cx file
   (included in some common header).)

-- 
Bartc

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

#100027

BartC <bc@freeuk.com> writes:
<snip>
>> BartC <bc@freeuk.com> writes:
>
>>> A68: if a;b then c;d;e elif f then g elif h then i;j else k fi
>>>
>>> C:   if (a,b) {c;d;e;} else if (f) g; else if (h) {i;j;} else k;
>> <snip>
>>> - There are probably more placement styles for { and } than are
>>>   possible with the A68 scheme; yet more variability in code.
<snip>
> But I'm actually thinking of my own syntax which is derived from Algol
> 68

Ah.  It's a shame you wrote A68 then.

-- 
Ben.

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

#100028

>>> C:   if (a,b) {c;d;e;} else if (f) g; else if (h) {i;j;} else k;

C: if(a,b)c,d,e;else if(f)g;else if(h)i,j;else k;

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

#100030

On 22/12/2016 13:25, asetofsymbols@gmail.com wrote:
>>>> C:   if (a,b) {c;d;e;} else if (f) g; else if (h) {i;j;} else k;
>
> C: if(a,b)c,d,e;else if(f)g;else if(h)i,j;else k;
>

More variability...

But this is not quite the same, as a,b,c, etc represent arbitrary 
expressions and, when terminated with ";", arbitrary statements. So you 
can't change a;b; to a,b; in all cases.

-- 
Bartc

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

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

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

csiph-web