3 ms·

> Not quite. POSIX Nitpicking without measure is a man's greatest pleasure ;) You are not implementing POSIX. You are providing a hook for the library users a

> Not quite. POSIX Nitpicking without measure is a man's greatest pleasure ;) You are not implementing POSIX. You are providing a hook for the library users and your library will call this hook with (ptr, 0) when it wants to free a memory block. You just declare that your library works that way. Also, if your library wants, it can test provided hook to see if it complies with library's expected behavior and assert/fail if it doesn't. Think about it this way - if you are exposing a way to override realloc() calls in your library, then you will have to specify what your library means when it issues realloc(ptr, 0). So it's perfectly fine to declare that it expects such call to do what free() does, in which case a single realloc hook is sufficient to override all memory operations.

masklinn 13y ago
> Nitpicking without measure is a man's greatest pleasure ;) Pointing out that your assertion is tragically wrong is not nitpicking. > You are not implementing POSIX. Of course not, you're not implementing an OS. You're using POSIX. > You are providing a hook for the library users and your library will call this hook with (ptr, 0) when it wants to free a memory block. You just declare that your library works that way. This means it is not possible to pass through standard allocators to your library without your user having to know precisely how they handle the realloc case. This strikes me as a pretty significant annoyance for any user of said library. Oh, and your library can't rely on the platform's own allocators, so the user must provide an allocator for which he must know how realloc precisely behaves (and possibly wrap it) regardless of spec. > Think about it this way - if you are exposing a way to override realloc() calls in your library, then you will have to specify what your library means when it issues realloc(ptr, 0). If you stick with and expect POSIX semantics, as the name of the hook would imply, you don't have to specify anything and you simplify your library user's job. And think about it this way: if what you want is not realloc, don't call it realloc.

masklinn 13y ago

> Nitpicking without measure is a man's greatest pleasure ;) Pointing out that your assertion is tragically wrong is not nitpicking. > You are not implementing POSIX. Of course not, you're not implementing an OS. You're using POSIX. > You are providing a hook for the library users and your library will call this hook with (ptr, 0) when it wants to free a memory block. You just declare that your library works that way. This means it is not possible to pass through standard allocators to your library without your user having to know precisely how they handle the realloc case. This strikes me as a pretty significant annoyance for any user of said library. Oh, and your library can't rely on the platform's own allocators, so the user must provide an allocator for which he must know how realloc precisely behaves (and possibly wrap it) regardless of spec. > Think about it this way - if you are exposing a way to override realloc() calls in your library, then you will have to specify what your library means when it issues realloc(ptr, 0). If you stick with and expect POSIX semantics, as the name of the hook would imply, you don't have to specify anything and you simplify your library user's job. And think about it this way: if what you want is not realloc, don't call it realloc.