Segmentation fault, on the border ranges of int

Question

Create a function ft_range which returns an array ofints. This int array should contain all values between min and max. Min included - max excluded.

#include <printf.h>
#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>

#include <stdlib.h>

int *ft_range(int min, int max)
{
    int *ptrInt;
    int i;
    int temp;
    temp = min;
    i = 0;
    ptrInt = NULL;
    if (max < min)
    {
        return (ptrInt);
    } else
    {
        ptrInt = malloc(max - min);
    }
    while (i < (max - min))
    {
        *(ptrInt + i) = temp + i;
        i++; /trows segfault at i == 473742332
    }
    return (ptrInt);
}



int *ft_range(int min, int max);

int main()
{
    int i = 0;
    int min = -947483640;
    int max =  947483640;
    int *ptr = ft_range(min, max);

    while (ptr != NULL)
    {
        printf("%d", *ptr);
        printf("%c", '\n');
    }
}

If i put bigger values, segfault throws also on the bigger values. And this code works perfectly on the lower values.

`ptrInt = malloc(max - min); **-->>** ptrInt = malloc((max - min) *sizeof *ptrInt);` Also,most people prefer array-notation: `*(ptrInt + i) = temp + i;` **-->>** `ptrInt[i] = temp + i;` — wildplasser, Sep 26 '18 at 20:23
You're getting a segfault because you're invoking undefined behavior by writing past the size of the memory region that you've `malloc`ed. `malloc` accepts the number of bytes to allocate. `sizeof int` on your machine is surely larger than one byte, so simply allocating `max - min` bytes is not enough to store that many `int`s. After you fix your segfault, you're going to enter an infinite loop in `main`. `ptr` is never updated in your `while` loop. — yano, Sep 26 '18 at 20:28
If this is two separate source files, please indicate that. If not, normally all the `#include` directives go at the top of the file. — Keith Thompson, Sep 26 '18 at 20:34
There is also the corner case `min==max` , which is not caught by your check, but resulting in `malloc(0)` — wildplasser, Sep 26 '18 at 20:47

score 1 · Accepted Answer · answered Sep 26 '18 at 20:38

1

Code allocates insufficient memory when int is wider than char - something that is very common.

Allocate based on the size of the pointed to object. @wildplasser

int *ptrInt;
...
  // ptrInt = malloc(max - min);
  ptrInt = malloc(sizeof *ptrInt * (max - min));
  //              ^------------^   ^---------^ number of elements
  //              +------------+-------------- size of 1 element

answered Sep 26 '18 at 20:38

chux - Reinstate Monica

143,097
13
135
256

Is there a scenario where standard-conformant C does not have `int` wider than `char`? – Christian Gibbons Sep 26 '18 at 20:40
@ChristianGibbons Some graphics processors have been known to use the same 64-bit size for all integer types. Unusual, but allowed by C. – chux - Reinstate Monica Sep 26 '18 at 20:41
I unfortunately don't have time to go over the standard at the moment, but isn't a `char` guaranteed to be one byte (that is, such that byte is defined by `CHAR_BIT` or some-such), and an `int` guaranteed no less than two bytes? – Christian Gibbons Sep 26 '18 at 20:44
In C, a "byte" is at _least_ 8 bits. Research `CHAR_BIT`. A `char` uses `CHAR_BIT` bits - one C "byte". If `CHAR_BIT >= 16` then an `int` could also be 1 C "byte". – chux - Reinstate Monica Sep 26 '18 at 20:47
Alright, I'll take your word on that for now. I'll look it up in the standard later, but I trust that to be accurate. – Christian Gibbons Sep 26 '18 at 20:48
@ChristianGibbons [System where 1 byte != 8 bit?](https://stackoverflow.com/a/5516161/2410359) may be useful. – chux - Reinstate Monica Sep 26 '18 at 20:52

Segmentation fault, on the border ranges of int

1 Answers1