Is it possible sentence?

Discussion in 'C Programming' started by Alex, Jun 22, 2004.

  1. Alex

    Alex Guest

    Hi,

    I have a question regarding to string variable.

    Please look at below example.
    ------------------------------
    #define STR "ABC"

    char *testStr
    testStr = STR;
    ------------------------------

    I think above example have no problem.
    But I don't know where "ABC" is exist.
    Does C compiler make a memory for STR?

    -Alex-
    Alex, Jun 22, 2004
    #1
    1. Advertising

  2. Alex

    Chris Dollin Guest

    Alex wrote:

    > I have a question regarding to string variable.
    >
    > Please look at below example.
    > ------------------------------
    > #define STR "ABC"
    >
    > char *testStr


    (missing ;)

    > testStr = STR;


    (illegal at top level; assume we rewrite to

    chat *testStr = STR;
    )

    > ------------------------------
    >
    > I think above example have no problem.
    > But I don't know where "ABC" is exist.


    Somewhere. Somewhere where it will be valid for the
    entire program run. You don't need to know where.

    > Does C compiler make a memory for STR?


    Yes, but irrelevant; STR is a preprocessor symbol and is not visible
    at run-time (and need not and usually is not in compiled object code).

    --
    Chris "electric hedgehog" Dollin
    C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
    C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html
    Chris Dollin, Jun 22, 2004
    #2
    1. Advertising

  3. "Alex" <> wrote in message news:...
    > Hi,
    >
    > I have a question regarding to string variable.
    >
    > Please look at below example.
    > ------------------------------
    > #define STR "ABC"
    >
    > char *testStr
    > testStr = STR;


    This is perfectly correct if it appears inside a function. A statement
    in C must always be within a compound block.

    > ------------------------------
    >
    > I think above example have no problem.
    > But I don't know where "ABC" is exist.
    > Does C compiler make a memory for STR?
    >


    Your question, in general, is about storage of string literals. The answer
    varies under the following situations:

    * The Standard recommends the string literal to be a read-only; thus,
    allows sharing copies of string with identical text. In this
    case, the implementation may store the sting in the code section,
    or any other read-only section. This method helps perform some
    optimizations.

    * Many implementation provide extensions which are, generally, non
    portable. One such extension is writable string literals. The
    string is, then, stored in the program's static region. Thus, there
    would be different copies of string literal of identical text.

    Many compilers provide option to control the behaviour of character string
    literals. For example, gcc provide a compiler switch, -fwritable-strings, to
    store strings in writable data section. By default, GCC merges duplicate
    strings, whereas, Borland's Turbo C/C++ doesn't. It provides the following
    switches:

    -d merge duplicate string on
    -d- merge duplicate string off

    Many compilers provide pragmas to control, but these are non portable.
    The Standard(C99) specifies only few pragmas that are portable, and is out of
    scope here.

    > -Alex-


    --
    Vijay Kumar R Zanvar
    My Home Page - http://www.geocities.com/vijoeyz/
    Vijay Kumar R Zanvar, Jun 22, 2004
    #3
  4. "Vijay Kumar R Zanvar" <> wrote in message news:...
    >
    > "Alex" <> wrote in message news:...
    > > Hi,
    > >
    > > I have a question regarding to string variable.
    > >
    > > Please look at below example.
    > > ------------------------------
    > > #define STR "ABC"
    > >
    > > char *testStr


    Ah..missing semicolon.

    > > testStr = STR;

    >
    Vijay Kumar R Zanvar, Jun 22, 2004
    #4
  5. (Alex) wrote:
    >Hi,
    >
    >I have a question regarding to string variable.
    >
    >Please look at below example.
    >------------------------------
    >#define STR "ABC"
    >
    >char *testStr
    >testStr = STR;
    >------------------------------
    >
    >I think above example have no problem.
    >But I don't know where "ABC" is exist.
    >Does C compiler make a memory for STR?


    No. First, every occurrence of STR is literally replaced with "ABC"
    by the C preprocessor. Later in translation "ABC", like every source
    code string literal, is translated into an anonymous array object
    (in C the term 'object' means 'region of data storage which can hold
    values').

    Regards
    --
    Irrwahn Grausewitz ()
    welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
    clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
    clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
    Irrwahn Grausewitz, Jun 22, 2004
    #5
  6. Alex

    Dan Pop Guest

    In <> (Alex) writes:

    >I have a question regarding to string variable.
    >
    >Please look at below example.
    >------------------------------
    >#define STR "ABC"
    >
    >char *testStr;
    >testStr = STR;
    >------------------------------
    >
    >I think above example have no problem.


    Indeed, it is correct (after fixing an obvious typo).

    >But I don't know where "ABC" is exist.


    It is typically stored in either the data segment or the text segment
    of the program. If you can change it at runtime without crashing the
    program, then it's probably in the data segment. If the program crashes,
    it's in the text segment. Let's see:

    fangorn:~/tmp 192> cat test.c
    #define STR "ABC"

    int main()
    {
    char *testStr;
    testStr = STR;
    *testStr = 0;
    return *testStr;
    }
    fangorn:~/tmp 193> gcc test.c
    fangorn:~/tmp 194> ./a.out
    Segmentation fault

    So, it was in the text segment on my system/compiler combo.
    Some compilers allow the user to control this aspect:

    fangorn:~/tmp 195> gcc -fwritable-strings test.c
    fangorn:~/tmp 196> ./a.out
    fangorn:~/tmp 197> echo $status
    0

    >Does C compiler make a memory for STR?


    The STR identifier exists only during the preprocessing phase. By the
    time the proper compilation starts, it has already been replaced by the
    "ABC" string literal, so the compiler doesn't even get to "see" it.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Jun 22, 2004
    #6
  7. Alex

    Ralmin Guest

    "Dan Pop" <> wrote:
    > (Alex) writes:
    > > #define STR "ABC"
    > >
    > > char *testStr;


    Note: the semicolon in the above line was added by Dan, and was not in
    Alex's original post.

    Dan, lest anyone accuse you of turning into another ERT, please strictly
    uphold the rules of quoting. The most one should do to quoted text is to
    snip out parts or to reflow the text for a consistent line length. It is not
    acceptable to silently make additions, changes or improvements to someone's
    code. At the least, the quote symbol on that line (>) should be removed to
    indicate changes were made.

    --
    Simon.
    Ralmin, Jun 23, 2004
    #7
  8. Alex

    Jack Klein Guest

    On Tue, 22 Jun 2004 17:30:17 +0530, "Vijay Kumar R Zanvar"
    <> wrote in comp.lang.c:

    >
    > "Alex" <> wrote in message news:...
    > > Hi,
    > >
    > > I have a question regarding to string variable.
    > >
    > > Please look at below example.
    > > ------------------------------
    > > #define STR "ABC"
    > >
    > > char *testStr
    > > testStr = STR;

    >
    > This is perfectly correct if it appears inside a function. A statement
    > in C must always be within a compound block.
    >
    > > ------------------------------
    > >
    > > I think above example have no problem.
    > > But I don't know where "ABC" is exist.
    > > Does C compiler make a memory for STR?
    > >

    >
    > Your question, in general, is about storage of string literals. The answer
    > varies under the following situations:
    >
    > * The Standard recommends the string literal to be a read-only; thus,


    The Standard makes no recommendations at all as to whether string
    literals should be read-only or not. C++ defines string literals as
    having type array of const char, but C does not. A C string literal
    has the type of array of char, no const.

    Modifying a string literal in C is undefined behavior because the
    standard specifically states that it is, not because the characters
    may or may not be read-only.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
    Jack Klein, Jun 23, 2004
    #8
  9. Alex

    Jack Klein Guest

    On 22 Jun 2004 13:25:48 GMT, (Dan Pop) wrote in
    comp.lang.c:

    > In <> (Alex) writes:
    >
    > >I have a question regarding to string variable.
    > >
    > >Please look at below example.
    > >------------------------------
    > >#define STR "ABC"
    > >
    > >char *testStr;
    > >testStr = STR;
    > >------------------------------
    > >
    > >I think above example have no problem.

    >
    > Indeed, it is correct (after fixing an obvious typo).
    >
    > >But I don't know where "ABC" is exist.

    >
    > It is typically stored in either the data segment or the text segment


    Who says C programs have data segments and text segments? Chapter and
    verse.

    > of the program. If you can change it at runtime without crashing the
    > program, then it's probably in the data segment. If the program crashes,
    > it's in the text segment. Let's see:


    Let's not. A strictly conforming program can't tell what happens when
    a string literal is changed, since it ceases to be strictly conforming
    when it tries to perform the change.

    In most of the environments where the code I get paid to write
    executes, the undefined behavior of attempting to modify a string
    literal is ... nothing at all. The EPROM or Flash device in which the
    string literal is stored is totally unaffected by anything the
    processor can do to it in normal execution.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
    Jack Klein, Jun 23, 2004
    #9
  10. Alex

    Dan Pop Guest

    In <> "Ralmin" <> writes:

    >"Dan Pop" <> wrote:
    >> (Alex) writes:
    >> > #define STR "ABC"
    >> >
    >> > char *testStr;

    >
    >Note: the semicolon in the above line was added by Dan, and was not in
    >Alex's original post.


    Why would anyone bother to note such an irrelevant detail? Does it make
    any difference to the OP question or to my reply?

    >Dan, lest anyone accuse you of turning into another ERT, please strictly
    >uphold the rules of quoting. The most one should do to quoted text is to
    >snip out parts or to reflow the text for a consistent line length. It is not
    >acceptable to silently make additions, changes or improvements to someone's
    >code. At the least, the quote symbol on that line (>) should be removed to
    >indicate changes were made.


    Did you read the rest of my post with your brain engaged? Here's the
    relevant part:

    >I have a question regarding to string variable.
    >
    >Please look at below example.
    >------------------------------
    >#define STR "ABC"
    >
    >char *testStr;
    >testStr = STR;
    >------------------------------
    >
    >I think above example have no problem.


    Indeed, it is correct (after fixing an obvious typo).
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    In your humble opinion, what was the purpose of the parenthetical
    remark underlined above?

    The intent of the OP was perfectly clear, despite the missing semicolon
    in the original code. If I had any good reason to suspect that the OP
    omitted it *by ignorance*, I would have pointed out the syntax error.
    In the absence of any such reason, it was more constructive to fix the
    code AND mention that I've fixed it, rather than waste time uselessly
    pointing out the missing semicolon. I keep forgetting semicolons myself,
    on a regular basis, because my brain is focused on more important things
    when typing C code.

    It is not the first time I'm correcting trivial typos in posted code
    and expect a much harsher reply the next time you choose to make a
    fuss out of it.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Jun 23, 2004
    #10
  11. Alex

    Dan Pop Guest

    In <> Jack Klein <> writes:

    >On 22 Jun 2004 13:25:48 GMT, (Dan Pop) wrote in
    >comp.lang.c:
    >
    >> In <> (Alex) writes:
    >>
    >> >I have a question regarding to string variable.
    >> >
    >> >Please look at below example.
    >> >------------------------------
    >> >#define STR "ABC"
    >> >
    >> >char *testStr;
    >> >testStr = STR;
    >> >------------------------------
    >> >
    >> >I think above example have no problem.

    >>
    >> Indeed, it is correct (after fixing an obvious typo).
    >>
    >> >But I don't know where "ABC" is exist.

    >>
    >> It is typically stored in either the data segment or the text segment

    > ^^^^^^^^^
    >Who says C programs have data segments and text segments?


    No one. Do you have the slightest clue about the meaning of the word
    "typically"? In context, it means: "it is common practice to". If you
    have any sensible objection to my statement above, please make it. But
    keep the crap for yourself.

    >Chapter and verse.


    From what?

    >> of the program. If you can change it at runtime without crashing the
    >> program, then it's probably in the data segment. If the program crashes,
    >> it's in the text segment. Let's see:

    >
    >Let's not. A strictly conforming program can't tell what happens when
    >a string literal is changed, since it ceases to be strictly conforming
    >when it tries to perform the change.


    Therefore, I used a non-strictly conforming program to make my point.

    >In most of the environments where the code I get paid to write
    >executes, the undefined behavior of attempting to modify a string
    >literal is ... nothing at all.


    In most of the environments you're talking about, calling printf (without
    defining it) invokes undefined behaviour. So, should I avoid using
    printf because of that?

    Feel free to flame me when I start talking about segmentation faults or
    the ability to alter string literals in comp.arch.embedded. But make the
    effort to remember that the implementations we're talking about in c.l.c
    are, by default, hosted.

    Dan

    P.S. And your point was... ?

    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Jun 23, 2004
    #11
  12. Alex

    Jack Klein Guest

    On 23 Jun 2004 15:27:24 GMT, (Dan Pop) wrote in
    comp.lang.c:

    > In <> Jack Klein <> writes:
    >
    > >On 22 Jun 2004 13:25:48 GMT, (Dan Pop) wrote in
    > >comp.lang.c:

    >
    > >Let's not. A strictly conforming program can't tell what happens when
    > >a string literal is changed, since it ceases to be strictly conforming
    > >when it tries to perform the change.

    >
    > Therefore, I used a non-strictly conforming program to make my point.
    >
    > >In most of the environments where the code I get paid to write
    > >executes, the undefined behavior of attempting to modify a string
    > >literal is ... nothing at all.

    >
    > In most of the environments you're talking about, calling printf (without
    > defining it) invokes undefined behaviour. So, should I avoid using
    > printf because of that?
    >
    > Feel free to flame me when I start talking about segmentation faults or
    > the ability to alter string literals in comp.arch.embedded. But make the
    > effort to remember that the implementations we're talking about in c.l.c
    > are, by default, hosted.
    >
    > Dan
    >
    > P.S. And your point was... ?


    What part of:

    > Let's not. A strictly conforming program can't tell what happens when
    > a string literal is changed, since it ceases to be strictly conforming
    > when it tries to perform the change.


    ....didn't you understand?

    Describing what happens once a program invokes undefined behavior is
    not a C language issue and is quite off-topic here.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
    Jack Klein, Jun 25, 2004
    #12
  13. Alex

    Minti Guest

    Jack Klein <> wrote in message news:<>...
    > On 23 Jun 2004 15:27:24 GMT, (Dan Pop) wrote in
    > comp.lang.c:
    >
    > > In <> Jack Klein <> writes:
    > >
    > > >On 22 Jun 2004 13:25:48 GMT, (Dan Pop) wrote in
    > > >comp.lang.c:

    >
    > > >Let's not. A strictly conforming program can't tell what happens when
    > > >a string literal is changed, since it ceases to be strictly conforming
    > > >when it tries to perform the change.

    > >
    > > Therefore, I used a non-strictly conforming program to make my point.
    > >
    > > >In most of the environments where the code I get paid to write
    > > >executes, the undefined behavior of attempting to modify a string
    > > >literal is ... nothing at all.

    > >
    > > In most of the environments you're talking about, calling printf (without
    > > defining it) invokes undefined behaviour. So, should I avoid using
    > > printf because of that?
    > >
    > > Feel free to flame me when I start talking about segmentation faults or
    > > the ability to alter string literals in comp.arch.embedded. But make the
    > > effort to remember that the implementations we're talking about in c.l.c
    > > are, by default, hosted.
    > >
    > > Dan
    > >
    > > P.S. And your point was... ?

    >
    > What part of:
    >
    > > Let's not. A strictly conforming program can't tell what happens when
    > > a string literal is changed, since it ceases to be strictly conforming
    > > when it tries to perform the change.

    >
    > ...didn't you understand?
    >
    > Describing what happens once a program invokes undefined behavior is
    > not a C language issue and is quite off-topic here.



    So that means that saying that :

    "I coded it and @Nasal Daemons@ started flowing out my nose(?)" would
    be much better than saying that it might cause Segmentation fault. IMO
    opinion when a newbie asks a question it is much better to give a real
    perspective as to what *might* happen, rather than using terminology
    for which he might spend next half an hour searching the net, and
    which _might_ *never* happen.

    --
    Imanpreet Singh Arora
    isingh AT acm DOT org
    Minti, Jun 25, 2004
    #13
  14. Alex

    Dan Pop Guest

    In <> Jack Klein <> writes:

    >> Let's not. A strictly conforming program can't tell what happens when
    >> a string literal is changed, since it ceases to be strictly conforming
    >> when it tries to perform the change.

    >
    >...didn't you understand?


    What part of my previous text reflected my failure to understand this
    irrelevant remark?

    >Describing what happens once a program invokes undefined behavior is
    >not a C language issue and is quite off-topic here.


    You're confusing c.l.c and comp.std.c. If you can't tolerate discussions
    that go beyond the chapter and verse of the standard, c.l.c is not for
    you.

    The purpose (or one of the main purposes) of c.l.c is to help people
    learn C and practical issues are *as* important as the theoretical ones.
    People make programming mistakes and invoke undefined behaviour, as a
    result. Understanding the *practical* consequences of invoking undefined
    behaviour helps finding mistakes that led to invoking undefined behaviour.

    We also recommend people to carefully read and try to understand the
    diagnostics generated by their compilers, although there is no chapter
    and verse in the standard supporting such a recommendation. Are you
    strongly objecting to this recommendation, too? How about the one
    about not casting the return value of malloc? There is no chapter and
    verse forbidding it, right?

    You're kindly invited to remove your head from your arse. The brain
    can greatly benefit from the additional oxygen...

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Jun 25, 2004
    #14
  15. On Thu, 24 Jun 2004, Jack Klein wrote:

    > Describing what happens once a program invokes undefined behavior is
    > not a C language issue and is quite off-topic here.


    Google groups search: +"Jack Klein" +"DeathStation" and I
    found this:

    ``On the DeathStation 9000 it might mean launch nuclear
    missiles at Antarctica'' -- Jack Klein, 2002-06-22

    Tak-Shing
    Tak-Shing Chan, Jun 25, 2004
    #15
    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. Jluis
    Replies:
    3
    Views:
    698
    Riyaz
    May 5, 2004
  2. Geo
    Replies:
    0
    Views:
    476
  3. Geo
    Replies:
    6
    Views:
    521
  4. Matt
    Replies:
    11
    Views:
    52,427
    satyam000
    Aug 16, 2010
  5. Ian Pilcher
    Replies:
    0
    Views:
    3,770
    Ian Pilcher
    Dec 12, 2003
Loading...

Share This Page