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

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

C format programs

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

Contents

  C format programs songbird <songbird@anthive.com> - 2012-08-29 21:07 -0400
    Re: C format programs Don't make my brown eyes China Blue <chine.bleu@yahoo.com> - 2012-08-29 18:35 -0700
      Re: C format programs songbird <songbird@anthive.com> - 2012-08-29 21:50 -0400
        Re: C format programs ImpalerCore <jadill33@gmail.com> - 2012-08-29 20:32 -0700
          Re: C format programs songbird <songbird@anthive.com> - 2012-08-30 02:20 -0400
            Re: C format programs ImpalerCore <jadill33@gmail.com> - 2012-08-30 06:06 -0700
              Re: C format programs songbird <songbird@anthive.com> - 2012-08-30 22:44 -0400
      Re: C format programs Keith Thompson <kst-u@mib.org> - 2012-08-29 19:50 -0700
    Re: C format programs Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-29 21:35 -0400
      Re: C format programs songbird <songbird@anthive.com> - 2012-08-29 22:43 -0400
        Re: C format programs Ian Collins <ian-news@hotmail.com> - 2012-08-30 14:48 +1200
          Re: C format programs Keith Thompson <kst-u@mib.org> - 2012-08-29 19:58 -0700
            Re: C format programs songbird <songbird@anthive.com> - 2012-08-30 01:07 -0400
              Re: C format programs Adrian Ratnapala <raka@scooter.fritz.box> - 2012-09-01 07:10 +0000
          Re: C format programs Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-08-29 22:13 -0600
            Re: C format programs Ian Collins <ian-news@hotmail.com> - 2012-08-30 16:28 +1200
              Re: C format programs Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-08-30 08:55 -0600
                Re: C format programs Adrian Ratnapala <raka@scooter.fritz.box> - 2012-09-01 07:03 +0000
            Re: C format programs Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-09-06 15:52 +0300

#25473 — C format programs

  I dislike the use of macros which hide
the meaning of the code, but some code I
work on does things like the following and I
don't want to stray too far from the original
version.

  I tried both indent, and astyle and neither of
them understand macros enough to know what to do
with things like:


=====
# define when         break; case
# define orwhen         case
# define otherwise      break; default

=====

  so the result looks like:

=====

  /* Get the options */
  while (--argc > 0 && (*++argv)[0] == '-') {
    while (*++(*argv)) {
      switch (**argv) {
when 'a': full=2;
when 'i': init++;
when 'f': full=1;
when 'm': m = atoi(*argv+1); SKIPARG;
          printf ("axe size %d.\n", m);
when 's': seed = atoi(*argv+1); SKIPARG;
          printf ("Random seed %d.\n", m);
when 'v': version = atoi(*argv+1); SKIPARG;
          printf ("version %d.\n", version);
otherwise:  quit (1,
                            "Usage: axe [-if] [-msv<value>] [axed]\n");
      }
    }
  }

=====

  if there is a way to preprocess to expand the macros
without getting all the extra stuff that cpp includes
that could be done.

  or if there are any other C code formatters/indenters
that do understand macros I'd be glad to hear of them.


thanks for any ideas,


  songbird

[toc] | [next] | [standalone]

#25478

In article <nuq2h9-p77.ln1@ID-306963.user.uni-berlin.de>,
 songbird <songbird@anthive.com> wrote:

> # define when         break; case
> # define orwhen         case
> # define otherwise      break; default

>   if there is a way to preprocess to expand the macros
> without getting all the extra stuff that cpp includes
> that could be done.
> 
>   or if there are any other C code formatters/indenters
> that do understand macros I'd be glad to hear of them.

If you're using unix, you can expand the macros with something

    sed <plugh.c >plugh.ex.c \
        's/when/break; case/g' \
        's/orwhen/case/g' \
        's/otherwise/break; default/g'

Similar tools like perl, tcl, ed are available on a variety of OSes and can also 
do this kind of simple string substitution.

-- 
My name Indigo Montoya.  \\        Annoying Usenet one post at a time.
You flamed my father.     \'         At least I can stay in character.
Prepare to be spanked.   //               When you look into the void,
Stop posting that!      `/  the void looks into you, and fulfills you.

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

#25483

Don't make my brown eyes China Blue wrote:
...
> If you're using unix, you can expand the macros with something
>
>     sed <plugh.c >plugh.ex.c \
>         's/when/break; case/g' \
>         's/orwhen/case/g' \
>         's/otherwise/break; default/g'
>
> Similar tools like perl, tcl, ed are available on a variety of OSes and can also 
> do this kind of simple string substitution.

  yes, of course.

  i was thinking of a more general solution for
many other macros...  those three are only the
tip of the iceberg.


  songbird

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

#25491

On Aug 29, 9:50 pm, songbird <songb...@anthive.com> wrote:
> Don't make my brown eyes China Blue wrote:
> ...
>
> > If you're using unix, you can expand the macros with something
>
> >     sed <plugh.c >plugh.ex.c \
> >         's/when/break; case/g' \
> >         's/orwhen/case/g' \
> >         's/otherwise/break; default/g'
>
> > Similar tools like perl, tcl, ed are available on a variety of OSes and can also
> > do this kind of simple string substitution.
>
>   yes, of course.
>
>   i was thinking of a more general solution for
> many other macros...  those three are only the
> tip of the iceberg.

There are a couple of approaches that I can think of, both of which
involve sed or some other text processing scripting language of
choice.  Since I'm the most familiar with sed, here are the couple of
approaches that I would suggest.

1.  sed solution - Build a lookup table in the hold space when one
runs into a single line '#define' construct.  Then for each line that
doesn't contain a #define, paste the hold space contents into the
pattern space and perform a lookup table substitution regex.  Not for
the faint of heart.

http://sed.sourceforge.net/grabbag/tutorials/lookup_tables.txt

2.  sed + cpp solution - Create a special character sequence to
"comment out" preprocessor directives that you don't want cpp to
preprocess.  For example, one can replace the '#' character in front
of every non '#define' statement with some kind of escape sequence.
For example, one can use an autoconf like quadrigraph '# --> @%:@'.

@%:@include <stdio.h> (cpp will now ignore)

@%:@ifdef HAVE_STDINT_H
@%:@  include <stdint.h>
@%:@endif

To preserve comments, one can define another "quadrigraph" sequence to
preserve comments, perhaps '@|:@ for '//' and '@<:@' for '/*' and
'@:>@' for '*/' (probably don't need to do it for '*/').  There may be
other character sequences I'm missing.

Then you pass the source through your 'cpp' preprocessor to perform
the macro substitution, and then filter the results to reestablish the
original preprocessor commands in the #define preprocessed file by
replacing your "quadrigraphs" with your original character sequences.

I recommend something along the lines of option 2, as it seems a bit
easier than the straight up 'sed' route.

Best regards,
John D.

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

#25508

ImpalerCore wrote:
...
> There are a couple of approaches that I can think of, both of which
> involve sed or some other text processing scripting language of
> choice.  Since I'm the most familiar with sed, here are the couple of
> approaches that I would suggest.
>
> 1.  sed solution - Build a lookup table in the hold space when one
> runs into a single line '#define' construct.  Then for each line that
> doesn't contain a #define, paste the hold space contents into the
> pattern space and perform a lookup table substitution regex.  Not for
> the faint of heart.
>
> http://sed.sourceforge.net/grabbag/tutorials/lookup_tables.txt
>
> 2.  sed + cpp solution - Create a special character sequence to
> "comment out" preprocessor directives that you don't want cpp to
> preprocess.  For example, one can replace the '#' character in front
> of every non '#define' statement with some kind of escape sequence.
> For example, one can use an autoconf like quadrigraph '# --> @%:@'.
>
> @%:@include <stdio.h> (cpp will now ignore)
>
> @%:@ifdef HAVE_STDINT_H
> @%:@  include <stdint.h>
> @%:@endif
>
> To preserve comments, one can define another "quadrigraph" sequence to
> preserve comments, perhaps '@|:@ for '//' and '@<:@' for '/*' and
> '@:>@' for '*/' (probably don't need to do it for '*/').  There may be
> other character sequences I'm missing.
>
> Then you pass the source through your 'cpp' preprocessor to perform
> the macro substitution, and then filter the results to reestablish the
> original preprocessor commands in the #define preprocessed file by
> replacing your "quadrigraphs" with your original character sequences.
>
> I recommend something along the lines of option 2, as it seems a bit
> easier than the straight up 'sed' route.
>
> Best regards,
> John D.

  Thanks for your reply,  :)

  Looks quite possible, but I'll wait for a bit
and see if anyone else knows of a tool that will 
work.

  I'm trying a few others out and we'll see how 
they go.  Gotta take a break for a few days and
then I'll come back to it and see what has come up.

  Thanks everyone,


  songbird

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

#25531

On Aug 30, 2:21 am, songbird <songb...@anthive.com> wrote:
> ImpalerCore wrote:
>
> ...
>
>
>
>
>
>
>
>
>
> > There are a couple of approaches that I can think of, both of which
> > involve sed or some other text processing scripting language of
> > choice.  Since I'm the most familiar with sed, here are the couple of
> > approaches that I would suggest.
>
> > 1.  sed solution - Build a lookup table in the hold space when one
> > runs into a single line '#define' construct.  Then for each line that
> > doesn't contain a #define, paste the hold space contents into the
> > pattern space and perform a lookup table substitution regex.  Not for
> > the faint of heart.
>
> >http://sed.sourceforge.net/grabbag/tutorials/lookup_tables.txt
>
> > 2.  sed + cpp solution - Create a special character sequence to
> > "comment out" preprocessor directives that you don't want cpp to
> > preprocess.  For example, one can replace the '#' character in front
> > of every non '#define' statement with some kind of escape sequence.
> > For example, one can use an autoconf like quadrigraph '# --> @%:@'.
>
> > @%:@include <stdio.h> (cpp will now ignore)
>
> > @%:@ifdef HAVE_STDINT_H
> > @%:@  include <stdint.h>
> > @%:@endif
>
> > To preserve comments, one can define another "quadrigraph" sequence to
> > preserve comments, perhaps '@|:@ for '//' and '@<:@' for '/*' and
> > '@:>@' for '*/' (probably don't need to do it for '*/').  There may be
> > other character sequences I'm missing.
>
> > Then you pass the source through your 'cpp' preprocessor to perform
> > the macro substitution, and then filter the results to reestablish the
> > original preprocessor commands in the #define preprocessed file by
> > replacing your "quadrigraphs" with your original character sequences.
>
> > I recommend something along the lines of option 2, as it seems a bit
> > easier than the straight up 'sed' route.
>
> > Best regards,
> > John D.
>
>   Thanks for your reply,  :)
>
>   Looks quite possible, but I'll wait for a bit
> and see if anyone else knows of a tool that will
> work.
>
>   I'm trying a few others out and we'll see how
> they go.  Gotta take a break for a few days and
> then I'll come back to it and see what has come up.

If you are able to post an full example file that you want to process
using pastebin or a direct copy, I'd be willing to take a shot at it
this weekend.  If you're not familiar with 'sed', it's a great tool to
learn for tasks like these.  The issue is that most sed scripts of
this nature require quite a bit of tweaking to get robust enough to
work, and 'sed' is not the easiest scripting language to wrap your
head around once you want to do more than simple regex substitutions.

Best regards,
John D.

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

#25613

ImpalerCore wrote:
...
> If you are able to post an full example file that you want to process
> using pastebin or a direct copy, I'd be willing to take a shot at it
> this weekend.  If you're not familiar with 'sed', it's a great tool to
> learn for tasks like these.  The issue is that most sed scripts of
> this nature require quite a bit of tweaking to get robust enough to
> work, and 'sed' is not the easiest scripting language to wrap your
> head around once you want to do more than simple regex substitutions.

  Thanks.  Not needed now...

  I'm familiar with sed/awk so that isn't a problem.

  Several other indenters weren't going to work 
any better than astyle (which i'd already applied).

  I ended up compromising and only fixing the
few things that were confusing astyle.  Leaving
the rest of the macros alone for the moment.
It took about 2hrs to review the code looking
for things that got goobered up but it was only
a few spots.  All set, the task is done.


  songbird

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

#25488

Don't make my brown eyes China Blue <chine.bleu@yahoo.com> writes:
> In article <nuq2h9-p77.ln1@ID-306963.user.uni-berlin.de>,
>  songbird <songbird@anthive.com> wrote:
>
>> # define when         break; case
>> # define orwhen         case
>> # define otherwise      break; default
>
>>   if there is a way to preprocess to expand the macros
>> without getting all the extra stuff that cpp includes
>> that could be done.
>> 
>>   or if there are any other C code formatters/indenters
>> that do understand macros I'd be glad to hear of them.
>
> If you're using unix, you can expand the macros with something
>
>     sed <plugh.c >plugh.ex.c \
>         's/when/break; case/g' \
>         's/orwhen/case/g' \
>         's/otherwise/break; default/g'
>
> Similar tools like perl, tcl, ed are available on a variety of OSes
> and can also do this kind of simple string substitution.

Be sure to match `when`, `orwhen`, and `otherwise` as full words.  For
sed:

    s/\<when\>/break; case/g

et al.

Avoiding substitutions within string literals and comments is left
as an exercise (i.e., I'm too lazy to figure out how to do it).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#25479

On 8/29/2012 9:07 PM, songbird wrote:
> [...]
>    I tried both indent, and astyle and neither of
> them understand macros enough to know what to do
> with things like:
> [... bletcherous code snipped ...]

     Ugh.  The most fitting punishment would be to force the
author to maintain his own code -- after a five-year hiatus
to let him forget what his "clever" macros did before someone
else "improved" them ...

     There's a saying "Thou shalt not use the preprocessor to
violate the syntax," which I think is a little extreme taken
at face value but a good starting point nonetheless.  The author
of the code you're facing was apparently inexperienced enough
not to have encountered that adage, or self-important enough to
imagine it didn't apply to him.  Too bad.

>    if there is a way to preprocess to expand the macros
> without getting all the extra stuff that cpp includes
> that could be done.
>
>    or if there are any other C code formatters/indenters
> that do understand macros I'd be glad to hear of them.

     Question 10.18 in the c.l.c. FAQ <http://www.c-faq.com/>
mentions a few possibilities, although I myself cannot vouch
for them.  Good luck! -- you may need it ...

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#25486

Eric Sosman wrote:
>songbird wrote:
>> [...]
>>    I tried both indent, and astyle and neither of
>> them understand macros enough to know what to do
>> with things like:
>> [... bletcherous code snipped ...]
>
>      Ugh.  The most fitting punishment would be to force the
> author to maintain his own code -- after a five-year hiatus
> to let him forget what his "clever" macros did before someone
> else "improved" them ...

  Code written in the early 80s (not by me :) ).  
Quite a different age in terms of coding/development 
than now.  Part of what I'm doing with this project 
is learning different tools and ways of doing things 
that I didn't have back then.

>      There's a saying "Thou shalt not use the preprocessor to
> violate the syntax," which I think is a little extreme taken
> at face value but a good starting point nonetheless.  The author
> of the code you're facing was apparently inexperienced enough
> not to have encountered that adage, or self-important enough to
> imagine it didn't apply to him.  Too bad.

  :)

  Well, for sure it isn't something I do.  I'd 
rather be able to see without having to hunt down 
the definition as it may be different than what 
I'd expect.

  If it is code I'm working on a lot I turn the
macros into function calls as much as possible
and do the text substitutions.  But that makes
it hard to do comparisons to the originals to
see what of substance has changed...


>>    if there is a way to preprocess to expand the macros
>> without getting all the extra stuff that cpp includes
>> that could be done.
>>
>>    or if there are any other C code formatters/indenters
>> that do understand macros I'd be glad to hear of them.
>
>      Question 10.18 in the c.l.c. FAQ <http://www.c-faq.com/>
> mentions a few possibilities, although I myself cannot vouch
> for them.  Good luck! -- you may need it ...

  It's not looking good at the moment, but I'll keep nosing
around, thanks.


  songbird

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

#25487

On 08/30/12 02:43 PM, songbird wrote:
>
>    If it is code I'm working on a lot I turn the
> macros into function calls as much as possible
> and do the text substitutions.  But that makes
> it hard to do comparisons to the originals to
> see what of substance has changed...

Use your source control system.

Check in cosmetic changes on their own, never mix them with logic 
changes.  Then you should be able to isolate the former from the latter 
quite easily.

-- 
Ian Collins

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

#25489

Ian Collins <ian-news@hotmail.com> writes:
> On 08/30/12 02:43 PM, songbird wrote:
>>
>>    If it is code I'm working on a lot I turn the
>> macros into function calls as much as possible
>> and do the text substitutions.  But that makes
>> it hard to do comparisons to the originals to
>> see what of substance has changed...
>
> Use your source control system.
>
> Check in cosmetic changes on their own, never mix them with logic 
> changes.  Then you should be able to isolate the former from the latter 
> quite easily.

Yes, that's definitely a good idea.  But comparison can still be
difficult in some cases.

For example, suppose version 5 is very old, version 10 removes the
ugly macros (so the only difference between versions 9 and 10 is
the cleanup), and version 15 is the current version.  If you need
to compare versions 5 and 15, or even 8 and 11, you're still going
to see a mixture of functional changes and cleanup changes.

If you can completely automate the process of fixing the macros,
in a way that works correctly even for older versions, you can
compare a converted copy of version 5 against version 15.

On the other hand, if versions of the code prior to version 9 are
uninteresting, it's probably not worth the effort; automating the
cleanup is likely to be worthwhile anyway, but don't worry about
automating 100% of it vs. 95%.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#25509

Keith Thompson wrote:
> Ian Collins writes:
>> songbird wrote:
>>>
>>>    If it is code I'm working on a lot I turn the
>>> macros into function calls as much as possible
>>> and do the text substitutions.  But that makes
>>> it hard to do comparisons to the originals to
>>> see what of substance has changed...
>>
>> Use your source control system.
>>
>> Check in cosmetic changes on their own, never mix them with logic 
>> changes.  Then you should be able to isolate the former from the latter 
>> quite easily.
>
> Yes, that's definitely a good idea.  But comparison can still be
> difficult in some cases.

  Yes, it's too noisy to be helpful.  I'm going to
have to step all the way back to the initial check-in
and then do the formatting there before going forwards
again with the changes.


> For example, suppose version 5 is very old, version 10 removes the
> ugly macros (so the only difference between versions 9 and 10 is
> the cleanup), and version 15 is the current version.  If you need
> to compare versions 5 and 15, or even 8 and 11, you're still going
> to see a mixture of functional changes and cleanup changes.
>
> If you can completely automate the process of fixing the macros,
> in a way that works correctly even for older versions, you can
> compare a converted copy of version 5 against version 15.
>
> On the other hand, if versions of the code prior to version 9 are
> uninteresting, it's probably not worth the effort; automating the
> cleanup is likely to be worthwhile anyway, but don't worry about
> automating 100% of it vs. 95%.

  I have it set up fairly automatic right now 
and it almost works exactly as i'd like.


  songbird

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

#25690

On 2012-08-30, songbird <songbird@anthive.com> wrote:
>   Yes, it's too noisy to be helpful.  I'm going to
> have to step all the way back to the initial check-in
> and then do the formatting there before going forwards
> again with the changes.

Ouch.  The nasty thing is that the hardest merges tend to be where
cosmetic changes have been made on one of the branches.  You get
conflicts everywhere, because of small one-character changes.

(But from the rest of the post, it seems like you only want look at the
old revisions.  That should be fine, not re-merge the costmetic
changes).

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

#25493

Ian Collins <ian-news@hotmail.com> writes:

> On 08/30/12 02:43 PM, songbird wrote:
>>
>>    If it is code I'm working on a lot I turn the
>> macros into function calls as much as possible
>> and do the text substitutions.  But that makes
>> it hard to do comparisons to the originals to
>> see what of substance has changed...
>
> Use your source control system.
>
> Check in cosmetic changes on their own, never mix them with logic
> changes.  Then you should be able to isolate the former from the
> latter quite easily.

If you can cleanly separate your cosmetic changes from your logic
changes when working on code, to the point you can make a bunch of
changes that *only* fit one of those categories at a time, my hat is off
to you as a disciplined programmer.

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

#25497

On 08/30/12 04:13 PM, Joe Pfeiffer wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>
>> On 08/30/12 02:43 PM, songbird wrote:
>>>
>>>     If it is code I'm working on a lot I turn the
>>> macros into function calls as much as possible
>>> and do the text substitutions.  But that makes
>>> it hard to do comparisons to the originals to
>>> see what of substance has changed...
>>
>> Use your source control system.
>>
>> Check in cosmetic changes on their own, never mix them with logic
>> changes.  Then you should be able to isolate the former from the
>> latter quite easily.
>
> If you can cleanly separate your cosmetic changes from your logic
> changes when working on code, to the point you can make a bunch of
> changes that *only* fit one of those categories at a time, my hat is off
> to you as a disciplined programmer.

Well that depends how often you commit.  In my case it's every few 
minutes.  I always have a never mix the two rule for my teams.

-- 
Ian Collins

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

#25540

Ian Collins <ian-news@hotmail.com> writes:

> On 08/30/12 04:13 PM, Joe Pfeiffer wrote:
>> Ian Collins<ian-news@hotmail.com>  writes:
>>
>>> On 08/30/12 02:43 PM, songbird wrote:
>>>>
>>>>     If it is code I'm working on a lot I turn the
>>>> macros into function calls as much as possible
>>>> and do the text substitutions.  But that makes
>>>> it hard to do comparisons to the originals to
>>>> see what of substance has changed...
>>>
>>> Use your source control system.
>>>
>>> Check in cosmetic changes on their own, never mix them with logic
>>> changes.  Then you should be able to isolate the former from the
>>> latter quite easily.
>>
>> If you can cleanly separate your cosmetic changes from your logic
>> changes when working on code, to the point you can make a bunch of
>> changes that *only* fit one of those categories at a time, my hat is off
>> to you as a disciplined programmer.
>
> Well that depends how often you commit.  In my case it's every few
> minutes.  I always have a never mix the two rule for my teams.

Ah, you commit far more frequently than I do.  I typically keep beating
on a single checkout until a bunch of changes is all in and working (so
several days), or until I want to move the work I'm doing from my
workstation to my laptop or vice versa.

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

#25689

>> Well that depends how often you commit.  In my case it's every few
>> minutes.  I always have a never mix the two rule for my teams.
>
> Ah, you commit far more frequently than I do.  I typically keep beating
> on a single checkout until a bunch of changes is all in and working (so
> several days), or until I want to move the work I'm doing from my
> workstation to my laptop or vice versa.

!!!

(Anyone know a good newsgroup for flame wors about version control
systems?)

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

#26004

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> Ian Collins <ian-news@hotmail.com> writes:
> > On 08/30/12 02:43 PM, songbird wrote:
> >>    If it is code I'm working on a lot I turn the
> >> macros into function calls as much as possible
> >> and do the text substitutions.  But that makes
> >> it hard to do comparisons to the originals to
> >> see what of substance has changed...
> >
> > Use your source control system.
> >
> > Check in cosmetic changes on their own, never mix them with logic
> > changes.  Then you should be able to isolate the former from the
> > latter quite easily.
> 
> If you can cleanly separate your cosmetic changes from your logic
> changes when working on code, to the point you can make a bunch of
> changes that *only* fit one of those categories at a time, my hat is off
> to you as a disciplined programmer.

As tree maintainer, I'd just Nack anything that didn't satisfy
Ian's advice. Nobody liked doing their patchset 3 times, they
eventually learn. ``git add -p'' is invaluable.

Phil, the guy who reached [PATCH v7]...
-- 
Regarding TSA regulations:
How are four small bottles of liquid different from one large bottle?
Because four bottles can hold the components of a binary liquid explosive,
whereas one big bottle can't. -- camperdave responding to MacAndrew on /.

[toc] | [prev] | [standalone]

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

csiph-web