Is the behaviour defined

Discussion in 'C Programming' started by grid, Oct 1, 2005.

  1. grid

    grid Guest

    Hi,
    A collegue of mine is of the opinion that the behaviour of the
    following program is defined,but I am a little apprehensive.

    #include<stdio.h>
    #include<string.h>

    int main()
    {
    char *c;
    c = &c;
    strcpy(c,"abc");
    puts(&c);
    retun 0;
    }

    The program prints the same value "abc" on multiple platforms and I even
    tried it with multiple compilers.I can make out that its trying to write
    to the pointer address and so probably the max it can write is 3 bytes +
    '\0'.But even if I try to copy more that 4 bytes it prints the whole
    string without any crashes.

    Changed line >> strcpy(c,"abcdefg");

    Now I know that this behaviour is undefined(writing more than 4 bytes)
    as the sizeof the pointer is 4 bytes(on the machine I tested on).

    Can anyone comment if this is compliant code and is the behaviour
    guaranteed.

    Thanks
    ~
    grid, Oct 1, 2005
    #1
    1. Advertising

  2. grid

    grid Guest

    > int main()
    > {
    > char *c;
    > c = &c;
    > strcpy(c,"abc");
    > puts(&c);
    > retun 0;
    > }

    It should be return 0;
    The spell of the return is wrong in the test program above.I did not
    have it in my test program which I compiled , but added it while
    composing this mail , of the fear of getting battered by the C language
    purists ;).
    grid, Oct 1, 2005
    #2
    1. Advertising

  3. grid wrote on 01/10/05 :
    > A collegue of mine is of the opinion that the behaviour of the following
    > program is defined,


    At minimum, it's implementation-dependent. But the result of putting
    any value in a pointer may have an undefined result (trap
    representation). There is a possibility of undefined behaviour.

    > but I am a little apprehensive.


    You can!

    > #include<stdio.h>
    > #include<string.h>
    >
    > int main()
    > {
    > char *c;
    > c = &c;


    Types are incompatible. (c is a char * and &c is a char**)

    > strcpy(c,"abc");


    The result of the 'sizeof char* == sizeof "abc"' expression is
    implementation-dependent.

    You need a space of 4 bytes for "abc".

    For example, on a x86 in real mode (16-bit) model small, pointers are
    16-bit wide, which means 2 bytes on this machine. Too small for "abc"

    > puts(&c);
    > retun 0;
    > }


    --
    Emmanuel
    The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
    The C-library: http://www.dinkumware.com/refxc.html

    ..sig under repair
    Emmanuel Delahaye, Oct 1, 2005
    #3
  4. "grid" <> wrote in message
    news:QKw%e.3$...
    > A collegue of mine is of the opinion that the behaviour of the
    > following program is defined,but I am a little apprehensive.
    >
    > #include<stdio.h>
    > #include<string.h>
    >
    > int main()
    > {
    > char *c;
    > c = &c;
    > strcpy(c,"abc");
    > puts(&c);
    > retun 0;
    > }


    The above code is broken. You attempt to store 4 chars/bytes
    (1+strlen("abc")==4) to the variable c, but you don't know whether c
    (pointer to a char) is big enough to hold 4 chars/bytes. On some platforms
    it can be 2 or even 1, hence you're risking to overwrite something else.
    Tell your collegue first to learn C better before advising a code such as
    the above.

    Alex
    Alexei A. Frounze, Oct 1, 2005
    #4
  5. grid

    grid Guest

    >> char *c;
    >> c = &c;

    >
    >
    > Types are incompatible. (c is a char * and &c is a char**)


    That is just to make c point to the first byte of the string.We will
    anyhow require a cast for this to silence the compiler, since they are
    really incompatible types as you mentioned

    c = (char *)&c;

    Thanks,
    ~
    grid, Oct 1, 2005
    #5
  6. grid wrote on 01/10/05 :
    >>> char *c;
    >>> c = &c;

    >>
    >> Types are incompatible. (c is a char * and &c is a char**)

    >
    > That is just to make c point to the first byte of the string.We will anyhow
    > require a cast for this to silence the compiler, since they are really
    > incompatible types as you mentioned
    >
    > c = (char *)&c;


    The result of the cast is implementation-dependent.

    --
    Emmanuel
    The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
    The C-library: http://www.dinkumware.com/refxc.html

    ..sig under repair
    Emmanuel Delahaye, Oct 1, 2005
    #6
  7. grid

    grid Guest

    > The above code is broken. You attempt to store 4 chars/bytes
    > (1+strlen("abc")==4) to the variable c, but you don't know whether c
    > (pointer to a char) is big enough to hold 4 chars/bytes. On some platforms
    > it can be 2 or even 1, hence you're risking to overwrite something else.


    I gave the example for my particular machine/hardware just to make it a
    point that this might not be a portable code.But apart from that, is it
    guaranteed to function as intended where the pointer sizes are 4 bytes
    or more.

    Also writing past 4 bytes on a machine with 4 byte pointers dosent seem
    to affect,though I am aware that undefined behaviour can really be
    anything and that could also mean that it dosent manifests itself at
    all.But this kind of non-compliant behaviour probably compels people to
    write non-portable code in the first place rather than any significant
    gain in efficiancy.

    Thanks
    ~
    grid, Oct 1, 2005
    #7
  8. "grid" <> wrote in message
    news:Fjx%e.6$...
    > > The above code is broken. You attempt to store 4 chars/bytes
    > > (1+strlen("abc")==4) to the variable c, but you don't know whether c
    > > (pointer to a char) is big enough to hold 4 chars/bytes. On some

    platforms
    > > it can be 2 or even 1, hence you're risking to overwrite something else.

    >
    > I gave the example for my particular machine/hardware just to make it a
    > point that this might not be a portable code.


    It's not portable. It's portable around your machine's hard drive, but not
    much further :) Or you should probably ask such portability and undefined
    behavior questions at comp.lang.c.x86 or something like that :)

    > But apart from that, is it
    > guaranteed to function as intended where the pointer sizes are 4 bytes
    > or more.


    I see no good reason for such code to exist at first place. Perhaps you
    could tell me it, if there is.
    It's much more easier and portable to declare a local 4-char array. If you
    need to use that space either for a pointer or for an array of 4 chars (one
    of them at a time), there's a union keyword for that.

    > Also writing past 4 bytes on a machine with 4 byte pointers dosent seem
    > to affect,though I am aware that undefined behaviour can really be
    > anything and that could also mean that it dosent manifests itself at
    > all.But this kind of non-compliant behaviour probably compels people to
    > write non-portable code in the first place rather than any significant
    > gain in efficiancy.


    Unportable code is the result of not following the standard (usually not
    knowning anything about it and not reading good books that were written with
    the standard in mind or not paying attention to those important details) but
    instead making own assumptions and relying on something that might or might
    not be true. If there's a need for any hardware/CPU-specific code, the
    proper way of doing it is to define the API and put portable code on one
    side of it and that platform specific code on the other side and never move
    a tiny bit of it to the portable part. Unportable code is mixing portable
    things with non-portable. Often times those non-portable things are due to
    writing say 4 when it must be sizeof(int) or sizeof(int*), improperly
    aligning data, improperly calculating sizes of structures and offsets of
    their members, reading/writing integers as bytes with big/little endian
    problems, ignoring casting to long in multiplication of ints (ignoring the
    fact that int and long aren't necessarily types of the same physical size),
    etc. The thing is, many books don't mention many practical things and hence
    the programmer must invent some way to them, often a quick and durty
    non-portable hack.

    Alex
    Alexei A. Frounze, Oct 1, 2005
    #8
  9. grid

    Flash Gordon Guest

    Emmanuel Delahaye wrote:
    > grid wrote on 01/10/05 :
    >
    >>>> char *c;
    >>>> c = &c;
    >>>
    >>> Types are incompatible. (c is a char * and &c is a char**)

    >>
    >> That is just to make c point to the first byte of the string.We will
    >> anyhow require a cast for this to silence the compiler, since they are
    >> really incompatible types as you mentioned
    >>
    >> c = (char *)&c;

    >
    > The result of the cast is implementation-dependent.


    Surely it is defined as producing a pointer to the first byte of c? If
    it was *not* (char*), (unsigned char*) or (signed char*) I would agree
    with you.
    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
    Flash Gordon, Oct 1, 2005
    #9
  10. grid <> writes:
    >> int main()
    >> {
    >> char *c;
    >> c = &c;
    >> strcpy(c,"abc");
    >> puts(&c);
    >> retun 0; }

    > It should be return 0;
    > The spell of the return is wrong in the test program above.I did not
    > have it in my test program which I compiled , but added it while
    > composing this mail , of the fear of getting battered by the C
    > language purists ;).


    This is why you should *always* copy-and-paste the actual code that
    you fed to the compiler, rather than re-typing it.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Oct 1, 2005
    #10
  11. grid

    SM Ryan Guest

    # Now I know that this behaviour is undefined(writing more than 4 bytes)
    # as the sizeof the pointer is 4 bytes(on the machine I tested on).

    Pointers aren't always four bytes. What you're looking for is
    sizeof c>=strlen(string)+1

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    Death is the worry of the living. The dead, like myself,
    only worry about decay and necrophiliacs.
    SM Ryan, Oct 1, 2005
    #11
  12. grid

    Joe Wright Guest

    grid wrote:
    >> int main()
    >> {
    >> char *c;
    >> c = &c;
    >> strcpy(c,"abc");
    >> puts(&c);
    >> retun 0; }

    >
    > It should be return 0;
    > The spell of the return is wrong in the test program above.I did not
    > have it in my test program which I compiled , but added it while
    > composing this mail , of the fear of getting battered by the C language
    > purists ;).


    Let me be the first to warn of impending doom. You define c an object of
    type char*. For sake of argument, the compiler arbitrarily places c at
    address 0100. Now you assign this address to c itself. If your warnings
    are high enough, you will be told about this. c has type char* while &c
    has type char**. The two are incompatible types.

    Assuming you got away with the assingment 'c = &c;' your c doesn't point
    to usable memory. With 'strcpy(c,"abc");' the Devil steps in, destroying
    c and anything else the Devil chooses. You are toast.

    Given the prototype in stdio.h as..

    int puts(const char *);

    What on earth do you think 'puts(&c);' will do?

    --
    Joe Wright
    "Everything should be made as simple as possible, but not simpler."
    --- Albert Einstein ---
    Joe Wright, Oct 2, 2005
    #12
  13. grid

    Chris Torek Guest

    In article <QKw%e.3$> grid <> wrote:
    > A collegue of mine is of the opinion that the behaviour of the
    >following program is defined, but I am a little apprehensive.
    >
    >#include<stdio.h>
    >#include<string.h>
    >
    >int main()
    >{
    > char *c;
    > c = &c;
    > strcpy(c,"abc");
    > puts(&c);
    > retun 0;
    >}


    This code does not even compile:

    % strictcc t.c
    t.c: In function `main':
    t.c:7: error: assignment from incompatible pointer type
    t.c:9: error: passing arg 1 of `puts' from incompatible pointer type
    t.c:10: syntax error before `0'
    %

    Fixing the obvious typo (so that line 10 says "return" instead of
    "retun") still gives two error messages and no executable.

    Adding the two obvious casts gives a program that fails when run
    on some machines -- the "return" does something very bad, since
    the bytes beyond &c that were overwritten held the return stack
    frame. (Amazingly enough, it *does* work on both the Data General
    Eclipse and the Cray, with the casts.)

    >Can anyone comment if this is compliant code and is the behaviour
    >guaranteed.


    Obviously the answer (to both questions) is "no".
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
    Chris Torek, Oct 2, 2005
    #13
  14. grid

    SM Ryan Guest

    Joe Wright <> wrote:
    # grid wrote:
    # >> int main()
    # >> {
    # >> char *c;
    # >> c = &c;
    # >> strcpy(c,"abc");
    # >> puts(&c);
    # >> retun 0; }

    # Assuming you got away with the assingment 'c = &c;' your c doesn't point
    # to usable memory. With 'strcpy(c,"abc");' the Devil steps in, destroying

    It points to an n-char wide local variable, where n=sizeof c.

    # c and anything else the Devil chooses. You are toast.

    As long as you copy n-1 or fewer chars (+ null byte terminator),
    the only possible risk is if a pointer value in memory, not a
    register, can trap to some kind of representation error.

    # What on earth do you think 'puts(&c);' will do?

    If the pointer value is interpretable as a n-1 (or less)
    character string, it would print that string.

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    I have no idea what you just said.
    I get that alot.
    SM Ryan, Oct 2, 2005
    #14
  15. grid

    Joe Wright Guest

    SM Ryan wrote:
    > Joe Wright <> wrote:
    > # grid wrote:
    > # >> int main()
    > # >> {
    > # >> char *c;
    > # >> c = &c;
    > # >> strcpy(c,"abc");
    > # >> puts(&c);
    > # >> retun 0; }
    >
    > # Assuming you got away with the assingment 'c = &c;' your c doesn't point
    > # to usable memory. With 'strcpy(c,"abc");' the Devil steps in, destroying
    >
    > It points to an n-char wide local variable, where n=sizeof c.
    >
    > # c and anything else the Devil chooses. You are toast.
    >
    > As long as you copy n-1 or fewer chars (+ null byte terminator),
    > the only possible risk is if a pointer value in memory, not a
    > register, can trap to some kind of representation error.
    >
    > # What on earth do you think 'puts(&c);' will do?
    >
    > If the pointer value is interpretable as a n-1 (or less)
    > character string, it would print that string.
    >


    #include <stdio.h>
    #include <string.h>
    int main(void) {
    char *c;
    c = &c;
    strcpy(c, "abc");
    puts(&c);
    return 0;
    }

    smr.c: In function `main':
    smr.c:5: warning: assignment from incompatible pointer type
    smr.c:7: warning: passing arg 1 of `puts' from incompatible pointer type

    I assume you get similar results. Even if it "works" this is not a
    decent program.

    --
    Joe Wright
    "Everything should be made as simple as possible, but not simpler."
    --- Albert Einstein ---
    Joe Wright, Oct 2, 2005
    #15
  16. grid

    Joe Wright Guest

    Chris Torek wrote:
    > In article <QKw%e.3$> grid <> wrote:
    >
    >> A collegue of mine is of the opinion that the behaviour of the
    >>following program is defined, but I am a little apprehensive.
    >>
    >>#include<stdio.h>
    >>#include<string.h>
    >>
    >>int main()
    >>{
    >> char *c;
    >> c = &c;
    >> strcpy(c,"abc");
    >> puts(&c);
    >> retun 0;
    >>}

    >
    >
    > This code does not even compile:
    >
    > % strictcc t.c
    > t.c: In function `main':
    > t.c:7: error: assignment from incompatible pointer type
    > t.c:9: error: passing arg 1 of `puts' from incompatible pointer type
    > t.c:10: syntax error before `0'
    > %
    >
    > Fixing the obvious typo (so that line 10 says "return" instead of
    > "retun") still gives two error messages and no executable.
    >
    > Adding the two obvious casts gives a program that fails when run
    > on some machines -- the "return" does something very bad, since
    > the bytes beyond &c that were overwritten held the return stack
    > frame. (Amazingly enough, it *does* work on both the Data General
    > Eclipse and the Cray, with the casts.)
    >
    >
    >>Can anyone comment if this is compliant code and is the behaviour
    >>guaranteed.

    >
    >
    > Obviously the answer (to both questions) is "no".


    I use DJGPP and a batch file to invoke the compiler as..

    @echo off
    gcc -W -Wall -ansi -pedantic -s -O2 %1.c -o %1.exe -lm

    I get the same complaints as you except they are warnings. And there is
    an executable produced and it "works" in that it produces

    abc

    I'm not defending the program, I wonder why I get warnings and you get
    errors.

    --
    Joe Wright
    "Everything should be made as simple as possible, but not simpler."
    --- Albert Einstein ---
    Joe Wright, Oct 2, 2005
    #16
  17. "Joe Wright" <> wrote in message
    news:...
    ....
    > I use DJGPP and a batch file to invoke the compiler as..
    >
    > @echo off
    > gcc -W -Wall -ansi -pedantic -s -O2 %1.c -o %1.exe -lm

    ....
    > I'm not defending the program, I wonder why I get warnings and you get
    > errors.


    There is a command line switch telling the compiler to turn the warnings
    into errors, either
    -pedantic-errors
    or
    -Werror
    or both will do that -- I've never tried.

    Alex
    Alexei A. Frounze, Oct 2, 2005
    #17
  18. In article <>,
    Joe Wright <> wrote:
    ....
    >I use DJGPP and a batch file to invoke the compiler as..
    >
    >@echo off
    >gcc -W -Wall -ansi -pedantic -s -O2 %1.c -o %1.exe -lm
    >
    >I get the same complaints as you except they are warnings. And there is
    >an executable produced and it "works" in that it produces
    >
    >abc
    >
    >I'm not defending the program, I wonder why I get warnings and you get
    >errors.


    Obviously, because we don't know what's behind Chris's "strictcc" command.

    (But I suspect it is an invocation of some C compiler that includes a cmd
    line option akin to gcc's "-Werror")
    Kenny McCormack, Oct 2, 2005
    #18
  19. grid

    Chris Torek Guest

    In article <>
    Joe Wright <> wrote:
    [Given a source file for which the C standards require "diagnostics"
    >and using DJGPP,] I get the same complaints as you except they are
    >warnings. And there is an executable produced ... I wonder why I
    >get warnings and you get errors.


    I have a stricter compiler. (Or rather, essentially the same
    compiler with some minor gimmicking.)

    The C standards say that "a diagnostic" is required, after which
    anything may happen. Using "strictcc" I get a diagnostic and no
    executable. See also -Werror and/or -pedantic-errors.

    (At work, I use both Diab and gcc, which produce somewhat different
    sets of warnings. Some code I consider "just fine" produces warnings
    with Diab but not with gcc, e.g.:

    #define MIN(a, b) ((a) < (b) ? (a) : (b))
    ...
    x = MIN(x, limit);

    will draw a warning with Diab under some flags [I have not yet
    attempted to determine which ones]. Hence I cannot *always* have
    "all warnings treated as errors". It is nice to use "strictcc" or
    equivalent for personal projects, though, where I control all
    aspects of the project, not just the C source file in question.)
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
    Chris Torek, Oct 3, 2005
    #19
  20. grid

    Old Wolf Guest

    Chris Torek wrote:
    > grid <> wrote:
    >>
    >>#include<stdio.h>
    >>#include<string.h>
    >>
    >>int main()
    >>{
    >> char *c;
    >> c = &c;
    >> strcpy(c,"abc");
    >> puts(&c);
    >> retun 0;
    >>}

    >
    > This code does not even compile:
    > Adding the two obvious casts gives a program that fails when run
    > on some machines -- the "return" does something very bad, since
    > the bytes beyond &c that were overwritten held the return stack
    > frame.


    How about the 'fixed' version:

    #include <stdio.h>
    #include <string.h>

    int main(void)
    {
    if ( sizeof(char *) >= sizeof "abc" )
    {
    char *c;
    c = (char *)&c;
    strcpy(c,"abc");
    puts(&c);
    }
    return 0;
    }

    I think this is always well-defined. It's legal to cast any
    object's address to (char *) and that pointer must point to
    the object's representation. It's legal to modify memory
    that has been allocated by you. This code never actually
    evaluates "c" after the strcpy, so the issue of a trap
    representation doesn't arise.
    Old Wolf, Oct 3, 2005
    #20
    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. Oodini
    Replies:
    1
    Views:
    1,750
    Keith Thompson
    Sep 27, 2005
  2. Angel Tsankov
    Replies:
    1
    Views:
    853
    Victor Bazarov
    Apr 5, 2006
  3. Replies:
    1
    Views:
    481
    Sion Arrowsmith
    Jul 10, 2008
  4. Keith Thompson

    Re: __STDC_IEC_559__ (defined or !defined ?)

    Keith Thompson, Aug 17, 2010, in forum: C Programming
    Replies:
    0
    Views:
    429
    Keith Thompson
    Aug 17, 2010
  5. Alok
    Replies:
    3
    Views:
    238
Loading...

Share This Page