Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Runtime errors possible when I forgot include <string.h>

Reply
Thread Tools

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

 
 
ABeck
Guest
Posts: n/a
 
      10-25-2005
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

 
Reply With Quote
 
 
 
 
Ravi Uday
Guest
Posts: n/a
 
      10-25-2005
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
>


 
Reply With Quote
 
 
 
 
Marc Boyer
Guest
Posts: n/a
 
      10-25-2005
Le 25-10-2005, ABeck <(E-Mail Removed)> 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
 
Reply With Quote
 
Joe Estock
Guest
Posts: n/a
 
      10-25-2005
Marc Boyer wrote:
> Le 25-10-2005, ABeck <(E-Mail Removed)> 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
 
Reply With Quote
 
Jordan Abel
Guest
Posts: n/a
 
      10-25-2005
On 2005-10-25, Marc Boyer <(E-Mail Removed)> wrote:
> Le 25-10-2005, ABeck <(E-Mail Removed)> 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

 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      10-25-2005
In article <(E-Mail Removed)>,
Jordan Abel <(E-Mail Removed)> 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.

 
Reply With Quote
 
Jordan Abel
Guest
Posts: n/a
 
      10-25-2005
On 2005-10-25, Kenny McCormack <(E-Mail Removed)> wrote:
> In article <(E-Mail Removed)>,
> Jordan Abel <(E-Mail Removed)> 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?
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-25-2005
Jordan Abel <(E-Mail Removed)> writes:
> On 2005-10-25, Marc Boyer <(E-Mail Removed)> wrote:
>> Le 25-10-2005, ABeck <(E-Mail Removed)> 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.velocityreviews.com/forums/(E-Mail Removed) <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.
 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      10-25-2005
In article <(E-Mail Removed)>,
Jordan Abel <(E-Mail Removed)> wrote:
>On 2005-10-25, Kenny McCormack <(E-Mail Removed)> wrote:
>> In article <(E-Mail Removed)>,
>> Jordan Abel <(E-Mail Removed)> 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.

 
Reply With Quote
 
Jordan Abel
Guest
Posts: n/a
 
      10-26-2005
On 2005-10-25, Kenny McCormack <(E-Mail Removed)> wrote:
> In article <(E-Mail Removed)>,
> Jordan Abel <(E-Mail Removed)> wrote:
>>On 2005-10-25, Kenny McCormack <(E-Mail Removed)> wrote:
>>> In article <(E-Mail Removed)>,
>>> Jordan Abel <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
/* #include <someyhing.h> */ => include it or do not include it?That is the question .... Andreas Bogenberger C Programming 3 02-22-2008 10:53 AM
Errors, errors, errors Mark Goldin ASP .Net 2 01-17-2004 08:05 PM
Re: the use of #include <a_file.h> v/s #include"a_file.cpp" Elie Nader C++ 1 11-28-2003 03:12 PM
Re: the use of #include <a_file.h> v/s #include"a_file.cpp" Rolf Magnus C++ 2 11-28-2003 12:26 PM
#include "bar" negates #include <string> ; how to fix? Danny Anderson C++ 5 08-15-2003 06:38 PM



Advertisments