C format programs

Discussion in 'C Programming' started by songbird, Aug 30, 2012.

  1. songbird

    songbird Guest

    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
    songbird, Aug 30, 2012
    #1
    1. Advertising

  2. songbird

    Eric Sosman Guest

    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
    d
    Eric Sosman, Aug 30, 2012
    #2
    1. Advertising

  3. songbird

    songbird Guest

    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
    songbird, Aug 30, 2012
    #3
  4. songbird

    songbird Guest

    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
    songbird, Aug 30, 2012
    #4
  5. songbird

    Ian Collins Guest

    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
    Ian Collins, Aug 30, 2012
    #5
  6. Don't make my brown eyes China Blue <> writes:
    > In article <-berlin.de>,
    > songbird <> 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) <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"
    Keith Thompson, Aug 30, 2012
    #6
  7. Ian Collins <> 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) <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"
    Keith Thompson, Aug 30, 2012
    #7
  8. songbird

    ImpalerCore Guest

    On Aug 29, 9:50 pm, songbird <> 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 andcan 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 '# --> @%:mad:'.

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

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

    To preserve comments, one can define another "quadrigraph" sequence to
    preserve comments, perhaps '@|:mad: for '//' and '@<:mad:' 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.
    ImpalerCore, Aug 30, 2012
    #8
  9. songbird

    Joe Pfeiffer Guest

    Ian Collins <> 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.
    Joe Pfeiffer, Aug 30, 2012
    #9
  10. songbird

    Ian Collins Guest

    On 08/30/12 04:13 PM, Joe Pfeiffer wrote:
    > Ian Collins<> 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
    Ian Collins, Aug 30, 2012
    #10
  11. songbird

    songbird Guest

    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
    songbird, Aug 30, 2012
    #11
  12. songbird

    songbird Guest

    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 '# --> @%:mad:'.
    >
    > @%:mad:include <stdio.h> (cpp will now ignore)
    >
    > @%:mad:ifdef HAVE_STDINT_H
    > @%:mad: include <stdint.h>
    > @%:mad:endif
    >
    > To preserve comments, one can define another "quadrigraph" sequence to
    > preserve comments, perhaps '@|:mad: for '//' and '@<:mad:' 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
    songbird, Aug 30, 2012
    #12
  13. songbird

    ImpalerCore Guest

    On Aug 30, 2:21 am, songbird <> 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 '# --> @%:mad:'.

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

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

    >
    > > To preserve comments, one can define another "quadrigraph" sequence to
    > > preserve comments, perhaps '@|:mad: for '//' and '@<:mad:' 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.
    ImpalerCore, Aug 30, 2012
    #13
  14. songbird

    Joe Pfeiffer Guest

    Ian Collins <> writes:

    > On 08/30/12 04:13 PM, Joe Pfeiffer wrote:
    >> Ian Collins<> 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.
    Joe Pfeiffer, Aug 30, 2012
    #14
  15. songbird

    songbird Guest

    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
    songbird, Aug 31, 2012
    #15
  16. >> 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?)
    Adrian Ratnapala, Sep 1, 2012
    #16
  17. On 2012-08-30, songbird <> 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).
    Adrian Ratnapala, Sep 1, 2012
    #17
  18. songbird

    Phil Carmody Guest

    Joe Pfeiffer <> writes:
    > Ian Collins <> 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 /.
    Phil Carmody, Sep 6, 2012
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    12
    Views:
    1,639
    Dave Thompson
    Jan 10, 2005
  2. Coca
    Replies:
    7
    Views:
    738
    Aidan Grey
    Aug 24, 2004
  3. Replies:
    18
    Views:
    619
    Dave Thompson
    Jan 10, 2005
  4. lone_eagle
    Replies:
    3
    Views:
    633
    psykeedelik
    May 26, 2009
  5. Casey Hawthorne
    Replies:
    14
    Views:
    446
Loading...

Share This Page