On Friday, 8 September 2023 at 07:59:37 UTC, rempas wrote:
I do have the following struct:

```d
struct Vec(T) {
private:
  T* _ptr = null; // The pointer to the data
u64 _cap = 0; // Total amount of elements (not bytes) we can store

public:
/* Create a vector by just allocating memory for it. The null terminator is not set for strings as, the vector is considered empty and we should first push something to it
     in order to use it! */
  this(i64 size) {
    this._len = 0;
    this._cap = size;

static if (is(T == char)) { size += 1; } // Additional space for the null terminator
    this._ptr = cast(T*)malloc(size);
  }
}
```

That's some minimal code that I do have just to showcase it. So, some times, this work will works, some others, it will give me the following error:

`Fatal glibc error: malloc.c:2594 (sysmalloc): assertion failed: (old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)`

The problem seems to happen when the pointer that is returned from `malloc` is assigned to the `_ptr` field. If I just assign it to a variable and don't assign anything to `_ptr`, it will work!

Is there any possible that there is a compiler bug? I do use ldc2 and `betterC`!



Hello, not completely unrelated to your problem, I have also done something like that, and when you're in D, don't use simply a pointer and length like that, use the `slice` operator.

See references:

https://tour.dlang.org/tour/en/basics/slices
https://dlang.org/spec/operatoroverloading.html#array-ops


For example, you can make your pointer a lot safer by doing:

```d
size_t length = 5;
int* pointer = cast(int*)malloc(int.sizeof * length); //Don't
int[] mallocArray = (cast(int*)malloc(int.sizeof * length))[0..length]; //Do
```

On the second way, you'll get bound checks, thus, making it safer. Also, no need to keep track of your length separately anymore.

This is good practice in D language and you'll find yourself using this instead in the future.

And yes, this works in betterC, it is a simple runtime check, completely `@nogc @safe nothrow` and every other kind of thing you would want.

Reply via email to