«

I have been messing around with buffers, and
I found it peculiar that the code below will
run without a segmentation fault.

As far as I know, overwriting the allocated space
from a call to malloc() results in undefined
behavior.

Any ideas why overwriting the dynamically
assigned space doesn't cause a segmentation
fault?

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

int
main(void)
{

char *ptr = NULL;
char buffer[256]; /* intentionally did not initialize */
int y = 0;

if ( ( ptr = malloc(1) ) == 0 ) {
perror("malloc() problem");
exit(1);
}

for ( int i; i < 255; i++ )
buffer[i] = 'Z';

while ( (ptr[y] = buffer[y]) != '\0' )
y++;
(void)printf("ptr is: %s\n", ptr);
free(ptr);

return 0;
}

On Thu, 08 Jul 2004 18:22:16 -0700, tweak <> wrote:

>As far as I know, overwriting the allocated space
>from a call to malloc() results in undefined
>behavior.
>
>Any ideas why overwriting the dynamically
>assigned space doesn't cause a segmentation
>fault?

Because undefined behavior by definition can be anything at all. You
were lucky, nothing more.

--
Eric Amick
Columbia, MD

tweak wrote:

> I have been messing around with buffers, and
> I found it peculiar that the code below will
> run without a segmentation fault.
>
> As far as I know, overwriting the allocated space
> from a call to malloc() results in undefined
> behavior.
>
> Any ideas why overwriting the dynamically
> assigned space doesn't cause a segmentation
> fault?

Why would you expect undefined behavior(UB) to cause seg fault?
To me, UB seems to suggest that anything can happen; good, bad, expected

or unexpected.

On Thu, 08 Jul 2004 18:22:16 -0700, tweak <>
wrote:

>
>I have been messing around with buffers, and
>I found it peculiar that the code below will
>run without a segmentation fault.
>
>As far as I know, overwriting the allocated space
>from a call to malloc() results in undefined
>behavior.
>
>Any ideas why overwriting the dynamically
>assigned space doesn't cause a segmentation
>fault?

Undefined behavior is not guaranteed to cause a segment fault. In its
most pernicious form, it appears to work properly until it can satisfy
one of Murphy's laws.

>
>#include <stdio.h>
>#include <stdlib.h>
>#include <string.h>
>#include <errno.h>
>
>int
>main(void)
>{
>
> char *ptr = NULL;
> char buffer[256]; /* intentionally did not initialize */
> int y = 0;
>
> if ( ( ptr = malloc(1) ) == 0 ) {
> perror("malloc() problem");
> exit(1);
> }
>
> for ( int i; i < 255; i++ )
> buffer[i] = 'Z';
>
> while ( (ptr[y] = buffer[y]) != '\0' )
> y++;
> (void)printf("ptr is: %s\n", ptr);
> free(ptr);
>
> return 0;
>}



<<Remove the del for email>>

Barry Schwarz wrote:
> On Thu, 08 Jul 2004 18:22:16 -0700, tweak <>
> wrote:
>
>
>>I have been messing around with buffers, and
>>I found it peculiar that the code below will
>>run without a segmentation fault.
>>
>>As far as I know, overwriting the allocated space
>
>>from a call to malloc() results in undefined
>
>>behavior.
>>
>>Any ideas why overwriting the dynamically
>>assigned space doesn't cause a segmentation
>>fault?
>
>
> Undefined behavior is not guaranteed to cause a segment fault. In its
> most pernicious form, it appears to work properly until it can satisfy
> one of Murphy's laws.

I tried different sizes of the buffer array, and I was able to generate
a segmentation fault. Since the compiler tells me everything is okay,
and since the software appears to work, are there any audit tools to
check for problems like this one, where the compiler doesn't warn of
a potential problem (beyond just the malloc() ones listed in the FAQ)?

I'm sure you grep or use an equivalent tool in the many different
OS's we have. But are there any portable tools?

Of course, writing ISO C99 code that is portable is preferred, but you
can miss stuff as the number of lines of code and number of files increase.

Brian

"tweak" <> wrote in message newsJpHc.787$rr.721@fed1read02...
> Barry Schwarz wrote:
> > On Thu, 08 Jul 2004 18:22:16 -0700, tweak <>
> > wrote:
[..]
> I tried different sizes of the buffer array, and I was able to generate
> a segmentation fault. Since the compiler tells me everything is okay,
> and since the software appears to work, are there any audit tools to
> check for problems like this one, where the compiler doesn't warn of
> a potential problem (beyond just the malloc() ones listed in the FAQ)?
>

lint may be helpful. See below.

> I'm sure you grep or use an equivalent tool in the many different
> OS's we have. But are there any portable tools?
>
> Of course, writing ISO C99 code that is portable is preferred, but you
> can miss stuff as the number of lines of code and number of files increase.
>
> Brian


> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <errno.h>
>
> int
> main(void)
> {
>
> char *ptr = NULL;
> char buffer[256]; /* intentionally did not initialize */
> int y = 0;
>
> if ( ( ptr = malloc(1) ) == 0 ) {
> perror("malloc() problem");
> exit(1);
> }
>
> for ( int i; i < 255; i++ )

i is uninitialized. UB.

> buffer[i] = 'Z';
>
> while ( (ptr[y] = buffer[y]) != '\0' )
> y++;
> (void)printf("ptr is: %s\n", ptr);
> free(ptr);
>
> return 0;
> }

F:\>splint overflow.c
Splint 3.0.1.6 --- 11 Feb 2002

overflow2.c: (in function main)
overflow2.c(15,1: Unrecognized identifier: NULL
Identifier used in code has not been declared. (Use -unrecog to inhibit
warning)
overflow2.c(19,19): Unrecognized identifier: malloc
overflow2.c(20,10): Unrecognized identifier: perror
overflow2.c(21,10): Unrecognized identifier: exit
overflow2.c(27,15): Index of possibly null pointer ptr: ptr
A possibly null pointer is dereferenced. Value is either the result of a
function which may return null (in which case, code should check it is not
null), or a global, parameter or structure field declared with the null
qualifier. (Use -nullderef to inhibit warning)
overflow2.c(19,19): Storage ptr may become null
overflow2.c(27,24): Value buffer[] used before definition
An rvalue is used that may not be initialized to a value on some execution
path. (Use -usedef to inhibit warning)
overflow2.c(29,12): Unrecognized identifier: printf
overflow2.c(30,6): Unrecognized identifier: free

Finished checking --- 8 code warnings

Vijay Kumar R Zanvar wrote:
> "tweak" <> wrote in message newsJpHc.787$rr.721@fed1read02...
>
>>Barry Schwarz wrote:
>>
>>>On Thu, 08 Jul 2004 18:22:16 -0700, tweak <>
>>>wrote:
>
> [..]
>
>>I tried different sizes of the buffer array, and I was able to generate
>>a segmentation fault. Since the compiler tells me everything is okay,
>>and since the software appears to work, are there any audit tools to
>>check for problems like this one, where the compiler doesn't warn of
>>a potential problem (beyond just the malloc() ones listed in the FAQ)?
>>
>
>
> lint may be helpful. See below.

Thanks. I used google to find it. I will start using it tomorrow.
I also found a splint. I will look at them both when I have more
energy.


>
>
>>I'm sure you grep or use an equivalent tool in the many different
>>OS's we have. But are there any portable tools?
>>
>>Of course, writing ISO C99 code that is portable is preferred, but you
>>can miss stuff as the number of lines of code and number of files increase.
>>
>>Brian
>
>
>
>>#include <stdio.h>
>>#include <stdlib.h>
>>#include <string.h>
>>#include <errno.h>
>>
>>int
>>main(void)
>>{
>>
>> char *ptr = NULL;
>> char buffer[256]; /* intentionally did not initialize */
>> int y = 0;
>>
>> if ( ( ptr = malloc(1) ) == 0 ) {
>> perror("malloc() problem");
>> exit(1);
>> }
>>
>> for ( int i; i < 255; i++ )
>
>
> i is uninitialized. UB.

Good catch. My source code reads as : for (int i = 0; i < 255; i++).
I made a typo.

Also since malloc() returns a NULL pointer on failure, the line that
starts with if should read:

if ( ( ptr = malloc(1) ) == NULL ) {

to be consistent even though it's just a style thing.

Thanks,

Brian

tweak <> wrote:

> > "tweak" <> wrote in message newsJpHc.787$rr.721@fed1read02...
> >> if ( ( ptr = malloc(1) ) == 0 ) {

> Also since malloc() returns a NULL pointer on failure,

No, it doesn't. It returns a null pointer. NULL is a macro, which
expands to a null pointer _constant_, and exists only in your source
code; a null pointer is an object, which exists during runtime.

> the line that starts with if should read:
>
> if ( ( ptr = malloc(1) ) == NULL ) {
>
> to be consistent even though it's just a style thing.

There's nothing consistent about it. The original is just as good, just
as clear, and just as proper C. The only way in which this version could
be more, rather than just as, consistent, is if you've used NULL
everywhere else in your code; but that is consistency with _yourself_,
not with C. C does not distinguish between those two versions; both must
work equally well.

Richard

In 'comp.lang.c', Eric Amick <eric-> wrote:

> On Thu, 08 Jul 2004 18:22:16 -0700, tweak <> wrote:
>
>>As far as I know, overwriting the allocated space
>>from a call to malloc() results in undefined
>>behavior.
>>
>>Any ideas why overwriting the dynamically
>>assigned space doesn't cause a segmentation
>>fault?
>
> Because undefined behavior by definition can be anything at all. You
> were lucky, nothing more.

I'd rather have said "you were unlucky".

--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

In 'comp.lang.c', tweak <> wrote:

> I have been messing around with buffers, and
> I found it peculiar that the code below will
> run without a segmentation fault.

May be it's correct, who knows ?

> As far as I know, overwriting the allocated space
> from a call to malloc() results in undefined
> behavior.

Yes.

> Any ideas why overwriting the dynamically
> assigned space doesn't cause a segmentation
> fault?

Why should do it ? An undefined behaviour in unpredictable. Anything may
happen, including a safe behaviour. Imagine you ask for 50 char. Some
implementation could give you the address of a 64 char block. You could write
at [50] to [63] safely.

The problem is that you don't know about the actual safe size. The C-language
only guarantees that the wanted size is safe. I know other implementations of
memory allocator (PSoS) where an additional parameter is used to return the
actual allocated size.

> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <errno.h>
>
> int
> main(void)
> {
>
> char *ptr = NULL;
> char buffer[256]; /* intentionally did not initialize */
> int y = 0;
>
> if ( ( ptr = malloc(1) ) == 0 ) {

Should be '== NULL' to preserve reader's mental health.

> perror("malloc() problem");
> exit(1);

exit (EXIT_FAILURE);

for portability.

> }
>
> for ( int i; i < 255; i++ )

Warning, This construct only works in C99.

> buffer[i] = 'Z';
>
> while ( (ptr[y] = buffer[y]) != '\0' )

Of course, you are overwriting the array pointed by ptr, but you know it
already.

> y++;

Because 'buffer' was intentionally not initialized, there is no guarantee
that a 0 is present at [255].

> (void)printf("ptr is: %s\n", ptr);

Can be anything.

> free(ptr);
>
> return 0;
> }


--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/