[std-discussion] C++17/C11 std::aligned_alloc unimplementable in Windows

[Myriachan]

The C++17 / C11 aligned_alloc() function is effectively unimplementable in
Windows. At least, not without updating the whole operating system.

The fundamental flaw with aligned_alloc() is that aligned_alloc() cannot be
implemented on top of an existing malloc() implementation because of the
need for free() to be able to free aligned_alloc() pointers. It has to be
integrated directly into the heap manager - which in the case of Windows
programs is not controlled by the application.

I suppose that it is possible to implement aligned_alloc() in Windows by
having all memory allocations at the C runtime level have an extra header
before calling Win32's HeapAlloc, but then you're hurting all malloc()s
just for the sake of supporting a very rare aligned_alloc().

This is really an unfortunate design flaw; if there were instead a separate
aligned_free() that were required, this wouldn't be a problem. Visual
Studio already has custom functions _aligned_malloc() and _aligned_free().

I don't work for Microsoft; I'm just pointing out something I know from
working with it so much.

Thanks,

Melissa

[Andrey Semashev]

The C++17 / C11 aligned_alloc() function is effectively unimplementable in Windows. At least, not without updating the whole operating system.
The fundamental flaw with aligned_alloc() is that aligned_alloc() cannot be implemented on top of an existing malloc() implementation because of the need for free() to be able to free aligned_alloc() pointers. It has to be integrated directly into the heap manager - which in the case of Windows programs is not controlled by the application.
I suppose that it is possible to implement aligned_alloc() in Windows by having all memory allocations at the C runtime level have an extra header before calling Win32's HeapAlloc, but then you're hurting all malloc()s just for the sake of supporting a very rare aligned_alloc().
This is really an unfortunate design flaw; if there were instead a separate aligned_free() that were required, this wouldn't be a problem. Visual Studio already has custom functions _aligned_malloc() and _aligned_free().

IMHO, Microsoft needs to do what every other operating system does -
support reclaiming memory allocated with aligned_alloc() with free().

[Hyman Rosen]

Post by Myriachan
The C++17 / C11 aligned_alloc() function is effectively unimplementable in
Windows. At least, not without updating the whole operating system.
The fundamental flaw with aligned_alloc() is that aligned_alloc() cannot
be implemented on top of an existing malloc() implementation because of the
need for free() to be able to free aligned_alloc() pointers. It has to be
integrated directly into the heap manager - which in the case of Windows
programs is not controlled by the application.
I suppose that it is possible to implement aligned_alloc() in Windows by
having all memory allocations at the C runtime level have an extra header
before calling Win32's HeapAlloc, but then you're hurting all malloc()s
just for the sake of supporting a very rare aligned_alloc().
This is really an unfortunate design flaw; if there were instead a
separate aligned_free() that were required, this wouldn't be a problem.
Visual Studio already has custom functions _aligned_malloc() and
_aligned_free().
I don't work for Microsoft; I'm just pointing out something I know from
working with it so much.

If you have Viusal Studio installed, you can have a look at malloc_base.cpp,
and you will see that it implements malloc by simply calling HeapAlloc.
That
means that HeapAlloc is already returning suitably aligned memory for the
purposes of malloc. Meanwhile, the C standard says that the alignment
argument of aligned_alloc must be a "valid alignment supported by the
implementation" so aligned_alloc is trivially implementable on Windows -
if the requested alignment is more than malloc provides then fail, otherwise
call malloc.

[Myriachan]

Post by Hyman Rosen

Post by Myriachan
The C++17 / C11 aligned_alloc() function is effectively unimplementable
in Windows. At least, not without updating the whole operating system.
The fundamental flaw with aligned_alloc() is that aligned_alloc() cannot
be implemented on top of an existing malloc() implementation because of the
need for free() to be able to free aligned_alloc() pointers. It has to be
integrated directly into the heap manager - which in the case of Windows
programs is not controlled by the application.
I suppose that it is possible to implement aligned_alloc() in Windows by
having all memory allocations at the C runtime level have an extra header
before calling Win32's HeapAlloc, but then you're hurting all malloc()s
just for the sake of supporting a very rare aligned_alloc().
This is really an unfortunate design flaw; if there were instead a
separate aligned_free() that were required, this wouldn't be a problem.
Visual Studio already has custom functions _aligned_malloc() and
_aligned_free().
I don't work for Microsoft; I'm just pointing out something I know from
working with it so much.

If you have Viusal Studio installed, you can have a look at
malloc_base.cpp,
and you will see that it implements malloc by simply calling HeapAlloc.
That
means that HeapAlloc is already returning suitably aligned memory for the
purposes of malloc. Meanwhile, the C standard says that the alignment
argument of aligned_alloc must be a "valid alignment supported by the
implementation" so aligned_alloc is trivially implementable on Windows -
if the requested alignment is more than malloc provides then fail, otherwise
call malloc.

This defeats the purpose of aligned_alloc, but yes, that technically
complies.

Melissa

[Marc]

Post by Myriachan
The C++17 / C11 aligned_alloc() function is effectively unimplementable in
Windows. At least, not without updating the whole operating system.

Note that this is really a C function, so you should take that up with
WG14. It isn't wrong for a C feature to require a new interface in some
operating system.

This is really an unfortunate design flaw; if there were instead a separate

Post by Myriachan
aligned_free() that were required, this wouldn't be a problem. Visual
Studio already has custom functions _aligned_malloc() and _aligned_free().

But we already have such a pair, called operator new and operator delete.
You can pass them an align_val_t argument. aligned_alloc should be limited
to cases where you specifically want compatibility with C and free().

[Dilip R]

Post by Myriachan
The C++17 / C11 aligned_alloc() function is effectively unimplementable in
Windows. At least, not without updating the whole operating system.

I am just trying to educate myself here but may I ask why you say this is
"effectively unimplementable"? and what specifically would cause the
operating system to be updated?

I ask because, I discussed this offline with a friend who lives & breathes
this kind of low level stuff for a living and he basically had the same
question as me.

[Thiago Macieira]

Post by Dilip R
I am just trying to educate myself here but may I ask why you say this is
"effectively unimplementable"? and what specifically would cause the
operating system to be updated?
I ask because, I discussed this offline with a friend who lives & breathes
this kind of low level stuff for a living and he basically had the same
question as me.

Because like most C things, the function has a "cop out'. The description of
the function is:

"The aligned_alloc function allocates space for an object whose alignment is
specified by alignment, whose size is specified by size, and whose value is
indeterminate. The value of alignment shall be a valid alignment supported by
the implementation and the value of size shall be an integral multiple of
alignment."

Note the "value of alignment shall be a valid alignment supported by the
implementation". If you pass an alignment that isn't supported, the function
is allowed to fail.

So yes, it's entirely implementable with current CRT. All it has to do is
refuse any alignment stricter than what malloc() already provides.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center