Re: Stringizing escape character tokens, std. or not?

Discussion in 'C Programming' started by Peter Nilsson, Jun 27, 2007.

  1. I think this post is better off in clc since it is asking
    how to apply the standard, rather than whether the standard
    itself is correctly worded.

    [Cross posted with followups set to clc.]

    James Antill <> wrote:
    > The short form of my question is, is this snippet valid C:
    >
    > #define FOO(x) "1234" #x "5678"
    >
    > const char *mystr1 = FOO(\n);
    > const char *mystr2 = FOO(\x20);
    >
    > ...as far as I can tell, it is.


    [It is.]

    > 6.10.3.2 implies that it "does the right thing" as
    > long as the input is a pre-processing token and the
    > output is a valid character string literal.
    > \n is two valid pre-processing tokens due to the
    > text at 6.4#3 and 6.4.6, and that is stringized and
    > then treated the same way as "\n" etc.
    >
    > Some background:
    >
    > The explanation of why I want to do this, is that
    > I want to create constant strings with a length at
    > the beginning and the nicest approach that I'm
    > leaning towards is:
    >
    > #define XSTR(x, y) #x y
    > const char *mystr = XSTR(\4, "1234");
    >
    > ...which seems nicer than the only real alternative of:
    >
    > #define XSTR(x, y) x y
    > const char *mystr = XSTR("\4", "1234");
    >
    > ...but if anyone knows of a nicer way of doing the above,
    > that would be even better :).


    Ditch the macro and just write...

    const char *mystr = "\4" "1234";

    ....or...

    const char *mystr = "\0041234";

    Note that octal can be confusing at a glance...

    const char *mystr = "\010" "12345678"; /* 10 or 8? */

    --
    Peter
     
    Peter Nilsson, Jun 27, 2007
    #1
    1. Advertising

  2. Peter Nilsson

    James Antill Guest

    On Tue, 26 Jun 2007 16:46:04 -0700, Peter Nilsson wrote:

    > I think this post is better off in clc since it is asking how to apply
    > the standard, rather than whether the standard itself is correctly
    > worded.
    >
    > [Cross posted with followups set to clc.]


    Well my main concern was to make sure it was legal, so csc was the right
    choice ... however knowing that I'm happy to discuss it too :).

    > James Antill <> wrote:
    >> The short form of my question is, is this snippet valid C:
    >>
    >> #define FOO(x) "1234" #x "5678"
    >>
    >> const char *mystr1 = FOO(\n);
    >> const char *mystr2 = FOO(\x20);
    >>
    >> ...as far as I can tell, it is.

    >
    > [It is.]
    >
    >> 6.10.3.2 implies that it "does the right thing" as
    >> long as the input is a pre-processing token and the output is a valid
    >> character string literal.
    >> \n is two valid pre-processing tokens due to the
    >> text at 6.4#3 and 6.4.6, and that is stringized and then treated the
    >> same way as "\n" etc.
    >>
    >> Some background:
    >>
    >> The explanation of why I want to do this, is that
    >> I want to create constant strings with a length at the beginning and
    >> the nicest approach that I'm leaning towards is:
    >>
    >> #define XSTR(x, y) #x y
    >> const char *mystr = XSTR(\4, "1234");
    >>
    >> ...which seems nicer than the only real alternative of:
    >>
    >> #define XSTR(x, y) x y
    >> const char *mystr = XSTR("\4", "1234");
    >>
    >> ...but if anyone knows of a nicer way of doing the above, that would be
    >> even better :).

    >
    > Ditch the macro and just write...
    >
    > const char *mystr = "\4" "1234";


    So the macro is there because life isn't quite as simple as the simple
    example. For a start you can have 1, 2, or 4 byte lengths ... and there's
    "stuff" that comes before the lengths, and there is a custom type on the
    left. So you can do:

    Ustr *s1 = USTR1(\x4, "abcd");
    Ustr *s2 = USTR2(\x1, \x23, "1234" [ ... 283 bytes ... ] "abcd");

    ....what I really wanted was to have something like:

    const char *s1 = (char []){ sizeof("...") }, "...";

    ....work, but if wishes were fishes…

    > ...or...
    >
    > const char *mystr = "\0041234";
    >
    > Note that octal can be confusing at a glance...
    >
    > const char *mystr = "\010" "12345678"; /* 10 or 8? */


    Yeh, it also gets really confusing if you have utf-8 bytes in the
    constant string. That pretty much requires running the code in debugging
    mode at some point (as debugging mode does check to make sure the length
    is correct).
    On the other hand I think a significant amount of the time people use
    small constant strings that aren't as confusing ... and I don't see a
    better solution.

    --
    James Antill --
    C String APIs use too much memory? ustr: length, ref count, size and
    read-only/fixed. Ave. 55% overhead over strdup(), for 0-20B strings
    http://www.and.org/ustr/
     
    James Antill, Jun 27, 2007
    #2
    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. Steven T. Hatton

    Template Stringizing-How should it work?

    Steven T. Hatton, Sep 10, 2004, in forum: C++
    Replies:
    2
    Views:
    1,197
    Steven T. Hatton
    Sep 10, 2004
  2. Siemel Naran

    syntax of stringizing macro

    Siemel Naran, Nov 6, 2004, in forum: C++
    Replies:
    8
    Views:
    1,917
    Old Wolf
    Nov 9, 2004
  3. Henry Townsend

    stringizing a hex value in the preprocessor

    Henry Townsend, Dec 2, 2005, in forum: C Programming
    Replies:
    14
    Views:
    819
  4. Ravi

    Stringizing

    Ravi, Nov 1, 2006, in forum: C Programming
    Replies:
    1
    Views:
    389
    Arthur J. O'Dwyer
    Nov 1, 2006
  5. slomo
    Replies:
    5
    Views:
    1,628
    Duncan Booth
    Dec 2, 2007
Loading...

Share This Page