User Activity

  • Posted a comment on ticket #779 on MinGW-w64 - for 32 and 64 bit Windows

    While that may be true currently, it can easily be wrapped with a malloc that overallocates and stores the offset in the spare bytes. Pretty much what _aligned_malloc does already (from how I understand what this seems to do https://github.com/Alexpux/mingw-w64/blob/master/mingw-w64-crt/misc/mingw-aligned-malloc.c ). What I hadn't thought of (and you undoubtably have) was API interoperability: With this change, MSVC couldn't free a buffer mingw-w64 code malloc-ed (unless there was some manual "unwrapping"...

  • Posted a comment on ticket #778 on MinGW-w64 - for 32 and 64 bit Windows

    for the second half / background info / related discussion see: https://sourceforge.net/p/mingw-w64/bugs/779/ Also mentioned there, I forgot to add here: This disparity only arises on i386. Also, the alignment of pointers returend by the current malloc implementation (described by the same/similar wording in the standard) is currently only 8, not 16.

  • Created ticket #779 on MinGW-w64 - for 32 and 64 bit Windows

    max_align_t definition outdated (on i386) since GCC 7

  • Created ticket #778 on MinGW-w64 - for 32 and 64 bit Windows

    max_align_t depends on header inclusion order

View All

Personal Data

Username:
rohlem
Joined:
2018-12-26 00:47:53

Projects

  • No projects to display.

Personal Tools