minux <minux...@gmail.com> writes: > Yes, the old_size is supposed to be the size of the originally > allocated memory block. But the problem is that some old gmp client > used to rely on the old_size behave as documented: > https://github.com/ghc/ghc/blob/d874b8c93b737bf26c949ef7bf19fc43e335bd1f/rts/sm/Storage.c#L935
Thanks, that's the first example I've seen of an application using old_size. In the alloc function (starting at line 913), it ends with SET_ARR_HDR(arr, &stg_ARR_WORDS_info, CCCS, data_size_in_words); /* and return a ptr to the goods inside the array */ return arr->payload; Maybe it would be easy for the realloc function to get the "arr" object back and get data size from here? > We couldn't just argue those clients are broken, because they > implemented realloc exactly according to the docs: > "The block may be moved if necessary or if desired, and in that case > the smaller of old_size and new_size bytes must be copied to the new > location." Sure, this code uses GMP correctly, according to GMP docs. And mini-gmp has a documentedly different behavior. > I consider the risk of passing a slightly smaller old_size in the case > of mpz_get_str is less risky because most allocations don't use > old_size for memory management purposes as you have observed. Maybe we should > document this difference for mini-gmp though. I don't really like such a subtle difference in documented behavior. Always passing zero is a less subtle uncompatibility, and will break applications depending on the GMP behavior in a more obvious way. If we change mini-gmp to be compatible with GMP here, I'd prefer to go all the way and make it fully compatible. But we should do that only if it's useful enough to warrant the extra complexity. ghc is one example, but it's still unclear to me (i) if it's hard or easy to fix the ghc allocator to use its own metadata, and (ii) what's the usecase and context for building ghc with mini-gmp. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
