alternate function names

Discussion in 'C Programming' started by phil-news-nospam@ipal.net, Dec 9, 2003.

  1. Guest

    This question is borderline between language and programming, but I want to
    focus more on the language standards issue, rather than the programming issue,
    so I am posting here.

    I have a number of functions which are front-ended by macros which make some
    changes in the way the functions are called. There are various things being
    done, but one simple example would be a function that takes a variable number
    of (const char *) arguments and joins all the strings together into a single
    string, where a NULL is the sentinel at the end of the arguments. The macro
    front end adds that NULL so the calling program is less cluttered with detail.

    What I have been doing with this is giving the macro the interface name and
    naming the function slightly different. I have been putting a "_" in front
    of the function name, which I want to get away from doing. So I have a macro
    like:
    #define strjoin(a...) (_strjoin(a,((const char*)(NULL))))
    and a function definition like:
    char *_strjoin(const char *s,...)

    The alternative I'm looking at is to just use the same name for both macro
    and function, like:
    #define strjoin(a...) ((strjoin)(a,((const char*)(NULL))))
    and:
    char *(strjoin)(const char *s,...)

    This approach works, but I'm worried about confusion it may cause. So what I
    want to do here is see if there is a better alternative to using a different
    function name than the one shown above. Would lots of "_" characters help
    avoid conflicts? Like maybe:
    #define strjoin(a...) (__strjoin__(a,((const char*)(NULL))))
    and:
    char *__strjoin__(const char *s,...)

    --
    -----------------------------------------------------------------------------
    | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
    | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
    -----------------------------------------------------------------------------
     
    , Dec 9, 2003
    #1
    1. Advertising

  2. Morris Dovey Guest

    Phil...

    Frankly, I'd rather code the NULL; and if I were a maintainer I
    would prefer to see the NULL than spend time puzzling over a macro.

    BTW, identifiers beginning with underscores or with "str" are
    reserved. My multi-string concatenator started out as strs() and
    became rtss() for this reason. )-:

    --
    Morris Dovey (WB0YEF)
    West Des Moines, Iowa USA
    C links at http://www.iedu.com/c
    Read my lips: The apple doesn't fall far from the tree.
     
    Morris Dovey, Dec 9, 2003
    #2
    1. Advertising

  3. Guest

    On Tue, 09 Dec 2003 13:09:56 -0600 Morris Dovey <> wrote:

    | Frankly, I'd rather code the NULL; and if I were a maintainer I
    | would prefer to see the NULL than spend time puzzling over a macro.

    I hold the opposite view. But if I were to find a suitable alternate name
    for the function itself, you could code direct function calls and use the
    NULL. I find it a big pain. My library is intended to remove many of the
    pains in programming while still giving me C level access.


    | BTW, identifiers beginning with underscores or with "str" are
    | reserved. My multi-string concatenator started out as strs() and
    | became rtss() for this reason. )-:

    I already have a huge number of string functions. But one thing they all
    do have is they begin with "str_" (the example I previously posted did not
    show a real name from that library). I think it is more important to have
    recognizable and understandable names for functions. I would not have
    guessed what rtss() is even about without you saying so. So what did you
    do, just reverse "str" to "rts" for everything?

    Footnote 146 in the last draft for C99 shows usage of an identifier that
    is reserved (7.1.3). What it's doing is hiding the reserved usage. So it
    would seem to imply that such reservations do not apply behinds the scenes.
    But it's unclear if this is an implemention C, or an implemention of something
    in C.

    --
    -----------------------------------------------------------------------------
    | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
    | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
    -----------------------------------------------------------------------------
     
    , Dec 9, 2003
    #3
  4. Simon Biber Guest

    <> wrote:
    > On Tue, 09 Dec 2003 13:09:56 -0600 Morris Dovey <> wrote:
    > | BTW, identifiers beginning with underscores or with "str" are
    > | reserved. My multi-string concatenator started out as strs() and
    > | became rtss() for this reason. )-:
    >
    > I already have a huge number of string functions. But one thing
    > they all do have is they begin with "str_" (the example I previously
    > posted did not show a real name from that library).


    Actually, "str_" is OK. The str prefix is only reserved when followed
    by a lowercase letter.

    Reserved identifiers include:

    is[abcdefghijklmnopqrstuvwxyz]*
    to[abcdefghijklmnopqrstuvwxyz]*
    cerf
    cerfc
    cexp2
    cexpm1
    clog10
    clog1p
    clog2
    clgamma
    ctgamma
    cerf[fl]
    cerfc[fl]
    cexp2[fl]
    cexpm1[fl]
    clog10[fl]
    clog1p[fl]
    clog2[fl]
    clgamma[fl]
    ctgamma[fl]
    E[0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ]*
    PRI[abcdefghijklmnopqrstuvwxyzX]*
    SCN[abcdefghijklmnopqrstuvwxyzX]*
    LC_[ABCDEFGHIJKLMNOPQRSTUVWXYZ]*
    SIG[ABCDEFGHIJKLMNOPQRSTUVWXYZ]*
    SIG_[ABCDEFGHIJKLMNOPQRSTUVWXYZ]*
    int*_t
    uint*_t
    INT*_MAX
    INT*_MIN
    INT*_C
    UINT*_MAX
    UINT*_MIN
    UINT*_C
    str[abcdefghijklmnopqrstuvwxyz]*
    mem[abcdefghijklmnopqrstuvwxyz]*
    wcs[abcdefghijklmnopqrstuvwxyz]*

    --
    Simon.
     
    Simon Biber, Dec 9, 2003
    #4
  5. Morris Dovey Guest

    wrote:

    > On Tue, 09 Dec 2003 13:09:56 -0600 Morris Dovey
    > <> wrote:
    >
    > | Frankly, I'd rather code the NULL; and if I were a
    > | maintainer I would prefer to see the NULL than spend time
    > | puzzling over a macro.
    >
    > I hold the opposite view. But if I were to find a suitable
    > alternate name for the function itself, you could code direct
    > function calls and use the NULL. I find it a big pain. My
    > library is intended to remove many of the pains in programming
    > while still giving me C level access.


    Understandable - in my case I seem to have spent too much of my
    career cleaning up other peoples' messes. It's been a real PIA to
    run into (really messy) macro definitions that I need to
    understand to eliminate as a contributor to the current mess; and
    too often the problem has at least involved one of these macros.

    > | BTW, identifiers beginning with underscores or with "str"
    > | are reserved. My multi-string concatenator started out as
    > | strs() and became rtss() for this reason. )-:
    >
    > I already have a huge number of string functions. But one
    > thing they all do have is they begin with "str_" (the example
    > I previously posted did not show a real name from that
    > library). I think it is more important to have recognizable
    > and understandable names for functions. I would not have
    > guessed what rtss() is even about without you saying so. So
    > what did you do, just reverse "str" to "rts" for everything?


    I think nearly everyone eventually has a similar collection. In
    my case, I did just what you inferred: I turned all the 'stirs'
    into 'rats' (str --> rts). Visit http://www.iedu.com/mrd/c for a
    representative sampling of the ugly naming.

    > Footnote 146 in the last draft for C99 shows usage of an
    > identifier that is reserved (7.1.3). What it's doing is
    > hiding the reserved usage. So it would seem to imply that
    > such reservations do not apply behinds the scenes. But it's
    > unclear if this is an implemention C, or an implemention of
    > something in C.


    For more than you'd ever want to know about the subject, do a
    Google groups search in comp.lang.c on "reserved str" (without
    quotes) and prepare to see this beaten to death ( repeatedly :)

    I adopted the attitude that since clients see my code I wouldn't
    embarrass myself more than absolutely necessary. I changed the
    names (growling all the while).
    --
    Morris Dovey
    West Des Moines, Iowa USA
    C links at http://www.iedu.com/c
    Read my lips: The apple doesn't fall far from the tree.
     
    Morris Dovey, Dec 9, 2003
    #5
  6. wrote in message news:<>...
    > This question is borderline between language and programming, but I want to
    > focus more on the language standards issue, rather than the programming issue,
    > so I am posting here.
    >
    > I have a number of functions which are front-ended by macros which make some
    > changes in the way the functions are called. There are various things being
    > done, but one simple example would be a function that takes a variable number
    > of (const char *) arguments and joins all the strings together into a single
    > string, where a NULL is the sentinel at the end of the arguments. The macro
    > front end adds that NULL so the calling program is less cluttered with detail.
    >
    > What I have been doing with this is giving the macro the interface name and
    > naming the function slightly different. I have been putting a "_" in front
    > of the function name, which I want to get away from doing. So I have a macro
    > like:
    > #define strjoin(a...) (_strjoin(a,((const char*)(NULL))))
    > and a function definition like:
    > char *_strjoin(const char *s,...)
    >
    > The alternative I'm looking at is to just use the same name for both macro
    > and function, like:
    > #define strjoin(a...) ((strjoin)(a,((const char*)(NULL))))
    > and:
    > char *(strjoin)(const char *s,...)
    >
    > This approach works, but I'm worried about confusion it may cause. So what I
    > want to do here is see if there is a better alternative to using a different
    > function name than the one shown above. Would lots of "_" characters help
    > avoid conflicts? Like maybe:
    > #define strjoin(a...) (__strjoin__(a,((const char*)(NULL))))
    > and:
    > char *__strjoin__(const char *s,...)


    I've often seen the macro named as the upper-case version of the function,
    so STRJOIN in your case. This is used to imply "essentially the same as
    the function, but doing some fiddling about first before either providing
    similar functionality or actually calling the function". It gives a clear
    hint that it's probably related to the function, but also makes clear that
    there must be something different about it.

    You shouldn't be using tokens beginning with underscore, or with 'str'
    followed by a lower case letter - they're reserved for the implementation.
    There are rules about exactly when they are reserved, but it's simplest
    to avoid them altogether.
     
    J. J. Farrell, Dec 10, 2003
    #6
  7. Derk Gwen Guest

    # What I have been doing with this is giving the macro the interface name and
    # naming the function slightly different. I have been putting a "_" in front
    # of the function name, which I want to get away from doing. So I have a macro
    # like:

    You can have a function name the same as a #define with arguments. Parenthesise
    the function name but not the #define:

    #define xyzzy(parrot) (xyzzy)(parrot-2,parrot+2)
    int (xyzzy)(int plugh,int plover);
    int (xyzzy)(int plugh,int plover) {
    return plugh*plover;
    }

    int main(int argc,char **argv) {
    printf("%d\n",(xyzzy)(4,8));
    printf("%d\n",xyzzy(6));
    return 0;
    }

    # #define strjoin(a...) (_strjoin(a,((const char*)(NULL))))
    # and a function definition like:
    # char *_strjoin(const char *s,...)
    #
    # The alternative I'm looking at is to just use the same name for both macro
    # and function, like:
    # #define strjoin(a...) ((strjoin)(a,((const char*)(NULL))))
    # and:
    # char *(strjoin)(const char *s,...)
    #
    # This approach works, but I'm worried about confusion it may cause. So what I
    # want to do here is see if there is a better alternative to using a different

    As long as you use #defines with arguments and parenthesise the function name,
    there will be no confusion in the compiler. (If you look at some of your
    implementation standard headers, you'll see them doing this trick.) Whether
    it confuses other programmers is a different issue.

    --
    Derk Gwen http://derkgwen.250free.com/html/index.html
    This is one wacky game show.
     
    Derk Gwen, Dec 10, 2003
    #7
  8. Guest

    On Wed, 10 Dec 2003 08:28:27 +1100 Simon Biber <> wrote:

    | Actually, "str_" is OK. The str prefix is only reserved when followed
    | by a lowercase letter.

    OK, glad to hear that.


    | Reserved identifiers include:

    Do you have a citation? A C99 section number would do. I didn't see
    it directly the way I searched, but maybe I missed an interpretation
    of different parts in different places apart from each other.


    | is[abcdefghijklmnopqrstuvwxyz]*

    I have a few is_* names.


    | str[abcdefghijklmnopqrstuvwxyz]*
    | mem[abcdefghijklmnopqrstuvwxyz]*

    And a few mem_* as well.

    --
    -----------------------------------------------------------------------------
    | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
    | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
    -----------------------------------------------------------------------------
     
    , Dec 10, 2003
    #8
  9. Guest

    On Tue, 09 Dec 2003 16:01:10 -0600 Morris Dovey <> wrote:

    | Understandable - in my case I seem to have spent too much of my
    | career cleaning up other peoples' messes. It's been a real PIA to
    | run into (really messy) macro definitions that I need to
    | understand to eliminate as a contributor to the current mess; and
    | too often the problem has at least involved one of these macros.

    Well, I hope that ultimately, my code won't need to be cleaned up.

    *knocks on wood* :)


    | I think nearly everyone eventually has a similar collection. In
    | my case, I did just what you inferred: I turned all the 'stirs'
    | into 'rats' (str --> rts). Visit http://www.iedu.com/mrd/c for a
    | representative sampling of the ugly naming.

    OK, you showed yours, I'll show mine:
    http://libh.slashusr.org/source/string/src/lib/h/

    The main library page is just:
    http://libh.slashusr.org/


    | For more than you'd ever want to know about the subject, do a
    | Google groups search in comp.lang.c on "reserved str" (without
    | quotes) and prepare to see this beaten to death ( repeatedly :)

    Being one to try things differently than told to do, I used the quotes :)
    Your post came in number 2 (searched by relevance mode). The first one
    that came up clarified a lot.

    --
    -----------------------------------------------------------------------------
    | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
    | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
    -----------------------------------------------------------------------------
     
    , Dec 10, 2003
    #9
  10. Guest

    On 9 Dec 2003 16:26:54 -0800 J. J. Farrell <> wrote:

    | I've often seen the macro named as the upper-case version of the function,
    | so STRJOIN in your case. This is used to imply "essentially the same as
    | the function, but doing some fiddling about first before either providing
    | similar functionality or actually calling the function". It gives a clear
    | hint that it's probably related to the function, but also makes clear that
    | there must be something different about it.

    I used to do that back when I didn't use macros very much. Now I use them
    quite a lot. Many are front ends to functions. Many are just used on their
    own without a function behind the scenes. I program using these functions
    and macros a lot. And I've found code with so much UPPER CASE ALL OVER is
    harder to read. Now I'm thinking more in terms of API design regardless of
    whether I implement as macro or function.


    | You shouldn't be using tokens beginning with underscore, or with 'str'
    | followed by a lower case letter - they're reserved for the implementation.
    | There are rules about exactly when they are reserved, but it's simplest
    | to avoid them altogether.

    Avoiding the beginning with underscore is the motivation of my original post
    for this thread. My example of strjoin() was a bad choice of name. The
    actual function is called str_dup_arg() because there are other variations
    that do things like copy or append to a target, and accept strings in forms
    like an array of pointers. You can view the actual source, still with the
    leading underscore on the function name (which hopefully by the next version
    will be changed), here:
    http://libh.slashusr.org/source/string/src/lib/h/str_dup_arg.c
    That whole section (string) is being majorly changed, which inspired this
    issue in the first place. Next version will be quite different.

    --
    -----------------------------------------------------------------------------
    | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
    | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
    -----------------------------------------------------------------------------
     
    , Dec 10, 2003
    #10
  11. Guest

    On Wed, 10 Dec 2003 01:44:15 -0000 Derk Gwen <> wrote:

    | # What I have been doing with this is giving the macro the interface name and
    | # naming the function slightly different. I have been putting a "_" in front
    | # of the function name, which I want to get away from doing. So I have a macro
    | # like:
    |
    | You can have a function name the same as a #define with arguments. Parenthesise
    | the function name but not the #define:
    |
    | #define xyzzy(parrot) (xyzzy)(parrot-2,parrot+2)
    | int (xyzzy)(int plugh,int plover);
    | int (xyzzy)(int plugh,int plover) {
    | return plugh*plover;
    | }

    Yes, that is being considered. And a lot of my functions already do that.
    But I'm trying to decide if that will confuse people or not. That issue
    I consider to not be a comp.lang.c question, and was planning to ask that
    on comp.programming instead. But to keep my options open, what I wanted
    to know from comp.lang.c was a suitable alternative to putting underscore
    in front of the name.


    | int main(int argc,char **argv) {
    | printf("%d\n",(xyzzy)(4,8));
    | printf("%d\n",xyzzy(6));
    | return 0;
    | }

    Things like this could be the confusion I want to avoid.


    | As long as you use #defines with arguments and parenthesise the function name,
    | there will be no confusion in the compiler. (If you look at some of your
    | implementation standard headers, you'll see them doing this trick.) Whether
    | it confuses other programmers is a different issue.

    And I have already done this in some functions. But now I want to get all my
    functions to be one way or the other, and hence the need to make a decision.

    --
    -----------------------------------------------------------------------------
    | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
    | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
    -----------------------------------------------------------------------------
     
    , Dec 10, 2003
    #11
  12. wrote:
    > On Wed, 10 Dec 2003 08:28:27 +1100 Simon Biber <> wrote:
    >

    <snip>
    > | Reserved identifiers include:

    <...>
    > Do you have a citation? A C99 section number would do. I didn't see
    > it directly the way I searched, but maybe I missed an interpretation
    > of different parts in different places apart from each other.


    ISO/IEC 9899:1999
    7.26.*
    7.1.3
    6.11.9
    6.10.8
    6.4.1

    Regards
    --
    Irrwahn Grausewitz ()
    welcome to clc : http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html
    clc faq-list : http://www.eskimo.com/~scs/C-faq/top.html
    acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~ajo/faqs/acllc-c .html
     
    Irrwahn Grausewitz, Dec 10, 2003
    #12
  13. Dan Pop Guest

    In <E6pBb.519$> Morris Dovey <> writes:

    >Phil...
    >
    >Frankly, I'd rather code the NULL; and if I were a maintainer I
    >would prefer to see the NULL than spend time puzzling over a macro.
    >
    >BTW, identifiers beginning with underscores or with "str" are
    >reserved. My multi-string concatenator started out as strs() and
    >became rtss() for this reason. )-:


    Only identifiers beginning with str followed by a lower case letter are
    reserved, so you could have used str_s() insteat of the rtss()
    abomination.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Dec 10, 2003
    #13
  14. Simon Biber Guest

    Phil Howard <> wrote:
    > Simon Biber <> wrote:
    > | Reserved identifiers include:
    >
    > Do you have a citation? A C99 section number would do. I didn't
    > see it directly the way I searched, but maybe I missed an
    > interpretation of different parts in different places apart from
    > each other.


    I generated that list directly from C99 7.26.*

    > | is[abcdefghijklmnopqrstuvwxyz]*
    >
    > I have a few is_* names.


    Which are fine, as is* are only reserved when followed by a
    lowercase letter.

    > | str[abcdefghijklmnopqrstuvwxyz]*
    > | mem[abcdefghijklmnopqrstuvwxyz]*
    >
    > And a few mem_* as well.


    Ditto.

    --
    Simon.
     
    Simon Biber, Dec 10, 2003
    #14
  15. Morris Dovey Guest

    Dan Pop wrote:

    > Only identifiers beginning with str followed by a lower case letter are
    > reserved, so you could have used str_s() insteat of the rtss()
    > abomination.


    Of course. Abomination, like beauty, is in the eye of the
    beholder. To this beholder, artificially expanding identifiers
    without adding semantic content is another abomination, because
    it "spoils" formatting efforts and helps to deplete my personal
    supply of newlines, tabs, and spaces. (-8

    It /is/ an aesthetic issue. Once the requirement to "uglify" a
    collection of functions (more than four dozen, most of which
    pre-dated any C standard) was recognized, it was a matter of
    choosing the /least/ abominable path.

    It was made still more irritating by the near certainty that the
    standard library would never be expanded in such a way as to
    produce name conflicts - that the reservation of str* and to* was
    done "because we can" and not "because it's essential" - and
    because the committee opted for "certain wholesale breakage now"
    rather than "possible retail breakage in the future" - a kind of
    decision making that strikes me as unwise and destructive, no
    matter how well-intended it might have been.

    [I already know that /everyone's/ mileage varies on this issue.]
    --
    Morris Dovey
    West Des Moines, Iowa USA
    C links at http://www.iedu.com/c
    Read my lips: The apple doesn't fall far from the tree.
     
    Morris Dovey, Dec 10, 2003
    #15
  16. Dan Pop Guest

    In <RVGBb.29$> Morris Dovey <> writes:

    >Dan Pop wrote:
    >
    >> Only identifiers beginning with str followed by a lower case letter are
    >> reserved, so you could have used str_s() insteat of the rtss()
    >> abomination.

    >
    >Of course. Abomination, like beauty, is in the eye of the
    >beholder. To this beholder, artificially expanding identifiers
    >without adding semantic content is another abomination, because
    >it "spoils" formatting efforts and helps to deplete my personal
    >supply of newlines, tabs, and spaces. (-8


    It's choosing the lesser evil. str_s is meaningful to anyone, rtss is
    meaningful to the insider only. No one would guess that rts is the
    reverse of the intended prefix and, therefore, the rtss identifier is as
    cryptical as you can get.

    Then again, if you write code for your own aesthetical gratification...

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Dec 10, 2003
    #16
    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. Ares Lagae
    Replies:
    8
    Views:
    462
    Ares Lagae
    Sep 24, 2004
  2. AC
    Replies:
    0
    Views:
    255
  3. Chris
    Replies:
    2
    Views:
    799
    Chris
    Mar 4, 2007
  4. News123
    Replies:
    2
    Views:
    485
    John Machin
    Nov 26, 2008
  5. Replies:
    10
    Views:
    368
    Sean O'Halpin
    Jul 17, 2006
Loading...

Share This Page