Runtime errors possible when I forgot include <string.h>

Discussion in 'C Programming' started by ABeck, Oct 25, 2005.

  1. ABeck

    ABeck Guest

    Hello List,

    I have ar more or less academical question.

    Can there arise runtime errors in a program, if the include of
    <string.h> has been forgotten? If all the arguments to the functions of
    <string.h> are correct, is it possible that an error occurs, and what
    an error might this be?

    Regards

    Alexander
    ABeck, Oct 25, 2005
    #1
    1. Advertising

  2. ABeck

    Ravi Uday Guest

    Yes, you will get undefined behaviour if you try to use any of the
    standard functions defined in <string.h> and not include the header.

    For ex:
    char *strcpy(char *dst, const char *src);

    char *strncpy(char *dst, const char *src, size_t n);

    char *strdup(const char *s1);

    char *strpbrk(const char *s1, const char *s2);

    char *strstr(const char *s1, const char *s2);

    char *strtok(char *s1, const char *s2);

    char *strtok_r(char *s1, const char *s2, char **lasts);

    all the above return 'char *' and are defined as a part of <string.h> \
    pkg, now if you dont include <string.h> and try using any of the above
    fns, then the compiler thinks those functions return 'int' (by default)
    and generate code in that way, this results in wrong interpretation of
    return values !

    - Ravi




    ABeck wrote:
    > Hello List,
    >
    > I have ar more or less academical question.
    >
    > Can there arise runtime errors in a program, if the include of
    > <string.h> has been forgotten? If all the arguments to the functions of
    > <string.h> are correct, is it possible that an error occurs, and what
    > an error might this be?
    >
    > Regards
    >
    > Alexander
    >
    Ravi Uday, Oct 25, 2005
    #2
    1. Advertising

  3. ABeck

    Marc Boyer Guest

    Le 25-10-2005, ABeck <> a écrit :
    > I have ar more or less academical question.
    >
    > Can there arise runtime errors in a program, if the include of
    ><string.h> has been forgotten? If all the arguments to the functions of
    ><string.h> are correct, is it possible that an error occurs, and what
    > an error might this be?


    Without include of <string.h>, all functions are 'implicitely
    defined', that is return value is supposed to be int and
    parameters are converted using 'default argument promotion'
    (6.5.2.2/6), ie integer promotion and float->double.

    So, the generated code could be incompatible with the
    implementation (UB). If implicit conversion between
    int and char* is unsafe (sizeof(int) < sizeof(char*)
    for example), then, strange things will occur.

    But, in most platform, implict conversion
    between int and char* behaves in a way such that
    the code runs.

    Marc Boyer
    Marc Boyer, Oct 25, 2005
    #3
  4. ABeck

    Joe Estock Guest

    Marc Boyer wrote:
    > Le 25-10-2005, ABeck <> a écrit :
    >
    >>I have ar more or less academical question.
    >>
    >>Can there arise runtime errors in a program, if the include of
    >><string.h> has been forgotten? If all the arguments to the functions of
    >><string.h> are correct, is it possible that an error occurs, and what
    >>an error might this be?

    >
    >
    > Without include of <string.h>, all functions are 'implicitely
    > defined', that is return value is supposed to be int and
    > parameters are converted using 'default argument promotion'
    > (6.5.2.2/6), ie integer promotion and float->double.
    >
    > So, the generated code could be incompatible with the
    > implementation (UB). If implicit conversion between
    > int and char* is unsafe (sizeof(int) < sizeof(char*)
    > for example), then, strange things will occur.
    >
    > But, in most platform, implict conversion
    > between int and char* behaves in a way such that
    > the code runs.
    >
    > Marc Boyer

    In some cases (depending on what functions are bing called and what
    compiler is used) the compiler will use it's own built-in function(s).
    Again, this depends on what functions are being used as well as the
    compiler.

    -Joe
    Joe Estock, Oct 25, 2005
    #4
  5. ABeck

    Jordan Abel Guest

    On 2005-10-25, Marc Boyer <> wrote:
    > Le 25-10-2005, ABeck <> a écrit :
    >> I have ar more or less academical question.
    >>
    >> Can there arise runtime errors in a program, if the include of <string.h>
    >> has been forgotten? If all the arguments to the functions of <string.h> are
    >> correct, is it possible that an error occurs, and what an error might this
    >> be?

    >
    > Without include of <string.h>, all functions are 'implicitely defined',
    > that is return value is supposed to be int and parameters are converted using
    > 'default argument promotion' (6.5.2.2/6), ie integer promotion and
    > float->double.
    >
    > So, the generated code could be incompatible with the implementation (UB).
    > If implicit conversion between int and char* is unsafe (sizeof(int) <
    > sizeof(char*) for example), then, strange things will occur.
    >
    > But, in most platform, implict conversion between int and char* behaves in
    > a way such that the code runs.


    "most"? That's a funny definition of 'most' you have there. Even on platforms
    where they're the same size they may be returned in different places. Many
    64-bit platforms now still have 32-bit int, and then there's still the odd LP32
    platform to deal with [16-bit int, 32-bit pointer]

    > Marc Boyer
    Jordan Abel, Oct 25, 2005
    #5
  6. In article <>,
    Jordan Abel <> wrote:
    (someone else wrote ">>")
    >> But, in most platform, implict conversion between int and char*
    >> behaves in a way such that the code runs.

    >
    >"most"? That's a funny definition of 'most' you have there. Even on
    >platforms where they're the same size they may be returned in different
    >places. Many 64-bit platforms now still have 32-bit int, and then there's
    >still the odd LP32 platform to deal with [16-bit int, 32-bit pointer]


    It is a practical, although obviously not clc-correct, definition.
    Kenny McCormack, Oct 25, 2005
    #6
  7. ABeck

    Jordan Abel Guest

    On 2005-10-25, Kenny McCormack <> wrote:
    > In article <>,
    > Jordan Abel <> wrote:
    > (someone else wrote ">>")
    >>> But, in most platform, implict conversion between int and char*
    >>> behaves in a way such that the code runs.

    >>
    >>"most"? That's a funny definition of 'most' you have there. Even on
    >>platforms where they're the same size they may be returned in different
    >>places. Many 64-bit platforms now still have 32-bit int, and then there's
    >>still the odd LP32 platform to deal with [16-bit int, 32-bit pointer]

    >
    > It is a practical, although obviously not clc-correct, definition.


    So basically by "most" you mean "your". I suppose you're on a vax, or a 386 of
    some kind?
    Jordan Abel, Oct 25, 2005
    #7
  8. Jordan Abel <> writes:
    > On 2005-10-25, Marc Boyer <> wrote:
    >> Le 25-10-2005, ABeck <> a écrit :
    >>> I have ar more or less academical question.
    >>>
    >>> Can there arise runtime errors in a program, if the include of <string.h>
    >>> has been forgotten? If all the arguments to the functions of <string.h> are
    >>> correct, is it possible that an error occurs, and what an error might this
    >>> be?

    >>
    >> Without include of <string.h>, all functions are 'implicitely
    >> defined', that is return value is supposed to be int and parameters
    >> are converted using 'default argument promotion' (6.5.2.2/6), ie
    >> integer promotion and
    >> float->double.
    >>
    >> So, the generated code could be incompatible with the
    >> implementation (UB). If implicit conversion between int and char*
    >> is unsafe (sizeof(int) < sizeof(char*) for example), then, strange
    >> things will occur.
    >>
    >> But, in most platform, implict conversion between int and char*
    >> behaves in a way such that the code runs.

    >
    > "most"? That's a funny definition of 'most' you have there. Even on
    > platforms where they're the same size they may be returned in
    > different places. Many 64-bit platforms now still have 32-bit int,
    > and then there's still the odd LP32 platform to deal with [16-bit
    > int, 32-bit pointer]


    There's nothing funny about it. "Most", in the sense of "the
    majority, but not all", is probably correct. 64-bit platforms,
    platforms with 16-bit ints and 32-bit pointers, and platforms that
    return integers and pointers in different registers are (I'm guessing)
    still in the minority.

    What this means, of course, is that on most systems the undefined
    behavior is more difficult to diagnose.

    --
    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 25, 2005
    #8
  9. In article <>,
    Jordan Abel <> wrote:
    >On 2005-10-25, Kenny McCormack <> wrote:
    >> In article <>,
    >> Jordan Abel <> wrote:
    >> (someone else wrote ">>")
    >>>> But, in most platform, implict conversion between int and char*
    >>>> behaves in a way such that the code runs.
    >>>
    >>>"most"? That's a funny definition of 'most' you have there. Even on
    >>>platforms where they're the same size they may be returned in different
    >>>places. Many 64-bit platforms now still have 32-bit int, and then there's
    >>>still the odd LP32 platform to deal with [16-bit int, 32-bit pointer]

    >>
    >> It is a practical, although obviously not clc-correct, definition.

    >
    >So basically by "most" you mean "your". I suppose you're on a vax, or
    >a 386 of some kind?


    I didn't know we were talking about me, but since you brought up the
    subject, let me say that this thread does bring back memories.

    When I first learned C, a million or so years ago, I was working on two
    platforms - Sun, which was/is 32/32, and another Unix platform, by
    a company whose name you wouldn't recognize, that happened to be 16/32.
    Until I learned about #include files, I was frequently surprised when my
    code, that worked fine on the Sun, crashed on the other platform. Make of
    this what you will.
    Kenny McCormack, Oct 25, 2005
    #9
  10. ABeck

    Jordan Abel Guest

    On 2005-10-25, Kenny McCormack <> wrote:
    > In article <>,
    > Jordan Abel <> wrote:
    >>On 2005-10-25, Kenny McCormack <> wrote:
    >>> In article <>,
    >>> Jordan Abel <> wrote:
    >>> (someone else wrote ">>")
    >>>>> But, in most platform, implict conversion between int and
    >>>>> char* behaves in a way such that the code runs.
    >>>>
    >>>>"most"? That's a funny definition of 'most' you have there. Even
    >>>>on platforms where they're the same size they may be returned in
    >>>>different places. Many 64-bit platforms now still have 32-bit
    >>>>int, and then there's still the odd LP32 platform to deal with
    >>>>[16-bit int, 32-bit pointer]
    >>>
    >>> It is a practical, although obviously not clc-correct,
    >>> definition.

    >>
    >>So basically by "most" you mean "your". I suppose you're on a vax,
    >>or a 386 of some kind?

    >
    > I didn't know we were talking about me, but since you brought up
    > the subject, let me say that this thread does bring back memories.


    Sorry - I tend to lose track of who I'm talking to - even when the
    attributions are there I only pay attention about half the time.

    > When I first learned C, a million or so years ago, I was working
    > on two platforms - Sun, which was/is 32/32, and another Unix
    > platform, by a company whose name you wouldn't recognize, that
    > happened to be 16/32. Until I learned about #include files, I was
    > frequently surprised when my code, that worked fine on the Sun,
    > crashed on the other platform. Make of this what you will.


    Didn't do much floating point code, huh? I suspect you'd have
    discovered the bugs much quicker in that case [while it sometimes
    appears safe to lack for a declaration of the string functions, it
    is never safe to do that for the math functions]

    I have had the dubious luxury of learning C in an era where, as the
    original poster said, most platforms are ILP32.
    Jordan Abel, Oct 26, 2005
    #10
  11. Marc Boyer wrote:
    > Le 25-10-2005, ABeck <> a écrit :
    > > I have ar more or less academical question.
    > >
    > > Can there arise runtime errors in a program, if the include of
    > > <string.h> has been forgotten? If all the arguments to the functions
    > > of <string.h> are correct, is it possible that an error occurs, and
    > > what an error might this be?

    >
    > Without include of <string.h>, all functions are 'implicitely
    > defined',


    Unless correctly declared elsewhere.

    > that is return value is supposed to be int and
    > parameters are converted using 'default argument promotion'
    > (6.5.2.2/6), ie integer promotion and float->double.
    >
    > So, the generated code could be incompatible with the
    > implementation (UB). If implicit conversion between
    > int and char* is unsafe (sizeof(int) < sizeof(char*)
    > for example), then, strange things will occur.
    >
    > But, in most platform, implict conversion
    > between int and char* behaves in a way such that
    > the code runs.


    There is no conversion in the C sense, implicit or otherwise.

    Even if they have the same size, ints and pointers may be returned
    in different registers. The return value may well be totally
    unrelated to the actual value returned by a given function.

    --
    Peter
    Peter Nilsson, Oct 26, 2005
    #11
  12. "Peter Nilsson" <> writes:
    > Marc Boyer wrote:
    >> Le 25-10-2005, ABeck <> a écrit :
    >> > I have ar more or less academical question.
    >> >
    >> > Can there arise runtime errors in a program, if the include of
    >> > <string.h> has been forgotten? If all the arguments to the functions
    >> > of <string.h> are correct, is it possible that an error occurs, and
    >> > what an error might this be?

    >>
    >> Without include of <string.h>, all functions are 'implicitely
    >> defined',

    >
    > Unless correctly declared elsewhere.
    >
    >> that is return value is supposed to be int and
    >> parameters are converted using 'default argument promotion'
    >> (6.5.2.2/6), ie integer promotion and float->double.
    >>
    >> So, the generated code could be incompatible with the
    >> implementation (UB). If implicit conversion between
    >> int and char* is unsafe (sizeof(int) < sizeof(char*)
    >> for example), then, strange things will occur.
    >>
    >> But, in most platform, implict conversion
    >> between int and char* behaves in a way such that
    >> the code runs.

    >
    > There is no conversion in the C sense, implicit or otherwise.
    >
    > Even if they have the same size, ints and pointers may be returned
    > in different registers. The return value may well be totally
    > unrelated to the actual value returned by a given function.


    Right.

    To expand on that a bit, what happens (even if ints and pointers are
    the same size and are returned in the same registers) is not a
    conversion; it's a reinterpretation of the bits. The function returns
    a char* value; the caller treats it as if it were an int.

    It's fairly (very?) common for an actual pointer-to-int conversion to
    be just a reinterpretation of the bits, but it needn't be.

    There likely will be a conversion if the caller explicitly casts the
    result to char* (to shut up the required diagnostic). This doesn't
    help, though.

    A similar situation occurs when the called function returns a double,
    and the caller (because of a failure to include the required header0
    interprets the result as an int. In this case, conversion from double
    to int almost certainly does require some computation rather than just
    a reinterpretation of the bits, and the result will be garbage.

    --
    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 26, 2005
    #12
  13. ABeck

    Marc Boyer Guest

    Le 25-10-2005, Jordan Abel <> a écrit :
    > On 2005-10-25, Marc Boyer <> wrote:
    >> Le 25-10-2005, ABeck <> a écrit :
    >>>
    >>> Can there arise runtime errors in a program, if the include of <string.h>
    >>> has been forgotten? If all the arguments to the functions of <string.h> are
    >>> correct, is it possible that an error occurs, and what an error might this
    >>> be?

    >>
    >> Without include of <string.h>, all functions are 'implicitely defined',
    >> that is return value is supposed to be int and parameters are converted using
    >> 'default argument promotion' (6.5.2.2/6), ie integer promotion and
    >> float->double.
    >>
    >> So, the generated code could be incompatible with the implementation (UB).
    >> If implicit conversion between int and char* is unsafe (sizeof(int) <
    >> sizeof(char*) for example), then, strange things will occur.
    >>
    >> But, in most platform, implict conversion between int and char* behaves in
    >> a way such that the code runs.

    >
    > "most"? That's a funny definition of 'most' you have there.


    Good news: I am always hapy to set a little fun in people life.

    > Even on platforms
    > where they're the same size they may be returned in different places. Many
    > 64-bit platforms now still have 32-bit int, and then there's still the odd LP32
    > platform to deal with [16-bit int, 32-bit pointer]


    Of course, 'many' is less ambigus than 'most'.

    Përhaps I could gives a more precise definition with something like
    'in most plateforms with a C programer developping and testing code on',
    but, this was an informal explanation, and I am feed up with
    experts playing this kind of game.
    If you want to make the list of all/some platforms and reasons
    where and why some truble could appear, do it.

    Marc Boyer
    Marc Boyer, Oct 26, 2005
    #13
    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. Mark Goldin

    Errors, errors, errors

    Mark Goldin, Jan 17, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    916
    Mark Goldin
    Jan 17, 2004
  2. Joe777

    I forgot to mention...

    Joe777, May 6, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    319
    Joe Van Meer
    May 6, 2004
  3. mglover

    forgot to mention

    mglover, Jul 22, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    801
    Bobby Ryzhy
    Jul 22, 2004
  4. Hal Vaughan
    Replies:
    11
    Views:
    1,081
    Gordon Beaton
    May 22, 2006
  5. Andreas Bogenberger
    Replies:
    3
    Views:
    875
    Andreas Bogenberger
    Feb 22, 2008
Loading...

Share This Page