[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: baby shell: code that compiles (for the most part), but indent doesn

From: Eric Deplagne
Subject: Re: baby shell: code that compiles (for the most part), but indent doesn't like it
Date: Tue, 11 Jun 2019 11:52:42 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Tue, 11 Jun 2019 02:33:39 -0700, L A Walsh wrote:
> On 2019/06/11 01:55, Eric Deplagne wrote:
> > On Sun, 09 Jun 2019 14:39:36 -0700, L A Walsh wrote:
> >   
> >>    I hand formatted it, and substituted in the value
> >> of the define: ",close(".  But the problem is since the compiler
> >> handles the above, shouldn't 'indent' be able to as well?
> >>     
> >
> >   Clearly, a #define with both "," and "(", NO.
> >   
> ?clearly? Clearly it doesn't and maybe you are saying it cannot, but whether
> or not it 'should' would depend on one's goals or what one wants to
> accomplish in the program.

  Clearly (it's here I add "i.m.o."), it should not even try to deal with
  #define messups.

> >   Just remember the preprocessor can do almost any dirty trick
> >   (is cpp formally turing complete or not ?).
> >   
> I would have no idea if any given instance of cpp is formally or informally
> turing complete.  Given the things one can do in macro languages as a
> form of declarative programming, I wouldn't doubt that someone might be able
> to prove it so, but I'm not sure how that would help w/the problem.

  Macro languages clearly are easily turing complete, I'm pretty sure m4 is,
  I have a little more doubt about cpp, but in any case it's almost.

  If it is actually turing complete, that means it can do just anything
  to our poor code, and indenting with defines taken into account is then
  just plain unfeasible.

> I thought the easiest way might be to have indent put markers around
> defines so that once a substitution was done, indent could do its normal
> processing and could find the markers and undo the substitution, resulting
> in something that should achieve that desired goal.
> However, I'd admit it was alot of work for what might be edge cases, so it
> really depends on how compete the implementor wants indent to be as compared
> to what a 'c' compiler handles.

  The C compiler actually handles fully preprocessed code, i.e. the output of 

  And it doesn't care if it's indented or in any way indentable.

> Whether it is fixed or not, isn't going to affect me much, as I don't
> use such convoluted constructs, as a general rule, in my own code (too much
> headache in maintenance later trying to figure out what I was doing!)
> As far as useful fixes, I'd much prefer to have had the RFE I submitted
> looked at, but I sorta realized it wasn't likely to happen after no
> comment(s) for a few months....*oh well*....supporting old SW is just really
> no fun if one has moved on to other things...and if it is no fun, how can
> you get motivated on something one did "on the side".  FWIW, the RFE I
> was talking about -- was the RFE I'll copy in below, but I'm not doing so
> much in C these days, so its probably not that important now either.
> Still, the above obfuscated code might make a good test case if it ever
> got to the point of being tested... :-)
> ----
> -------- Original Message --------
> Subject:      Fwd: RFE: option to 'cuddle' bracketless targets of
> conditional statements
> Date:         Mon, 23 Jan 2017 21:46:43 -0800
> From:         L A Walsh <address@hidden>
> To:   address@hidden
> I didn't see this option in my version of 'indent'
> (GNU indent 2.2.10), so forgive me if it is already there, but
> would it be possible to add an option to put or keep things like:
>  if (done) return done;
>  if (done)
>    return done;
>  for(i=0; i<100; ++i) printf("%d\n", i);
>  while (! done) done=get_status();
> on 1 line?
> Primarily thinking about bracketless targets that follow a conditional
> that easily fit on 1 line.
> Thanks!

  Eric Deplagne

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]