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

[ABeck]

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]

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

[Marc Boyer]

Le 25-10-2005, ABeck <al*******************@aei.mpg.de> 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

[Joe Estock]

Marc Boyer wrote:

Le 25-10-2005, ABeck <al*******************@aei.mpg.de> 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

[Jordan Abel]

On 2005-10-25, Marc Boyer <Ma********@enseeiht.yahoo.fr.invalid> wrote:

Le 25-10-2005, ABeck <al*******************@aei.mpg.de> 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

[Kenny McCormack]

In article <sl********************@random.yi.org>,
Jordan Abel <jm****@purdue.edu> 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.

[Jordan Abel]

On 2005-10-25, Kenny McCormack <ga*****@yin.interaccess.com> wrote:

In article <sl********************@random.yi.org>,
Jordan Abel <jm****@purdue.edu> 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?

[Keith Thompson]

Jordan Abel <jm****@purdue.edu> writes:

On 2005-10-25, Marc Boyer <Ma********@enseeiht.yahoo.fr.invalid> wrote:

Le 25-10-2005, ABeck <al*******************@aei.mpg.de> 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) ks***@mib.org <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.

[Kenny McCormack]

In article <sl********************@random.yi.org>,
Jordan Abel <jm****@purdue.edu> wrote:

On 2005-10-25, Kenny McCormack <ga*****@yin.interaccess.com> wrote:

In article <sl********************@random.yi.org>,
Jordan Abel <jm****@purdue.edu> 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.

[Jordan Abel]

On 2005-10-25, Kenny McCormack <ga*****@yin.interaccess.com> wrote:

In article <sl********************@random.yi.org>,
Jordan Abel <jm****@purdue.edu> wrote:

On 2005-10-25, Kenny McCormack <ga*****@yin.interaccess.com> wrote:

In article <sl********************@random.yi.org>,
Jordan Abel <jm****@purdue.edu> 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.

[Peter Nilsson]

Marc Boyer wrote:

Le 25-10-2005, ABeck <al*******************@aei.mpg.de> 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

[Keith Thompson]

"Peter Nilsson" <ai***@acay.com.au> writes:

Marc Boyer wrote:

Le 25-10-2005, ABeck <al*******************@aei.mpg.de> 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) ks***@mib.org <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.

[Marc Boyer]

Le 25-10-2005, Jordan Abel <jm****@purdue.edu> a écrit*:

On 2005-10-25, Marc Boyer <Ma********@enseeiht.yahoo.fr.invalid> wrote:

Le 25-10-2005, ABeck <al*******************@aei.mpg.de> 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