Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-443938 ] malloc routines use wrong cast
|
From: <no...@so...> - 2002-02-25 22:12:02
|
Bugs item #443938, was opened at 2001-07-23 15:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110894&aid=443938&group_id=10894 Category: 39. Memory Allocation Group: = 8.3.3 Status: Open Resolution: Invalid Priority: 4 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Donal K. Fellows (dkf) Summary: malloc routines use wrong cast Initial Comment: The malloc/ckalloc routines such as tcl_Allooc are defined with the size variable explicitly set to "unsigned int". They should be set to "size_t" (typdef in stdlib.h). When built on a 64 bit platform such as DEC TRU-64 or Solaris 8 (64 bit mode), this definition causes the programs to build improperly. There were also usages of strncmp and sizeof that were coded as if they were expected to return "unsigne int" instead of "size_t" (unsigned long). Compiled with gcc 3.0 as well as Solaris 8 Workshop 6.0 cc and DEC V5.1 cc ---------------------------------------------------------------------- >Comment By: Jeffrey Hobbs (hobbs) Date: 2002-02-25 14:11 Message: Logged In: YES user_id=72656 It has to be noted that ckalloc != malloc, so sticking with unsigned int is OK. You can't just always cast to long and think you are going to be able to alloc > 4GB of data on LP64 machines. This looks like something that may fall into the TIP 72 64-bit updates. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2001-11-14 01:35 Message: Logged In: YES user_id=79902 It is possible to upgrade the stub table so that new compilations use the new-type API but existing extensions use the old-type API (this is one of the things that Stubs gives us that no ordinary link mechanism can) but it is quite a bit of work. ---------------------------------------------------------------------- Comment By: Hillel (Sabba) Markowitz (sabbahillel) Date: 2001-11-13 13:52 Message: Logged In: YES user_id=286923 Then at the very least the "(unsigned) ckalloc" references should be changed to "(unsigned long) ckalloc" I went through the code by hand and the changes do appear to work correctly. Sab...@ve... or sab...@bc... ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2001-11-13 09:55 Message: Logged In: YES user_id=72656 int is 4 bytes on most systems, whereas size_t is 8. This will break binary compatability with all stubs-based extensions. IOW, no can do in 8.x. ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2001-11-12 23:48 Message: Logged In: YES user_id=7549 I agree with sabbahillel. If we let the native size of "The maximum number of bytes to which a pointer can refer" that size_t is (at least in ISO C), and express it to the outside, porting to 64 shouldn't be this hard as it is. Jeff, you refer to binary compatibility, but what is int??? Would that be the same as long, or __int32? Same problem for WIN64, too. ---------------------------------------------------------------------- Comment By: Hillel (Sabba) Markowitz (sabbahillel) Date: 2001-08-07 13:17 Message: Logged In: YES user_id=286923 The main problem seems to be that the size_t variables are declared as "(unsigned)" which defaults to "unsigned int". gcc points out that the parameters are a different width when long and int are different (in 64 bit mode). Even if it happens to work out, it should still be cased explicitly as (unsigned long) just to be certain. When compiled in 32 bit mode, it won't make a difference (since long = int) but it will make certain that 64 bit does not go bad. Even if it were not fatal, it would be better to do it correctly as the actual data passed through gets corrupted. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2001-08-07 10:15 Message: Logged In: YES user_id=72656 I'm still inclined to call this invalid, because I have compiled Tcl countless times on Solaris64 in 64-bit mode without fatal compilation errors (and it works), as well as Tru64. I'll look into it though (and make sure gcc isn't blowing smoke where the native compilers are OK). ---------------------------------------------------------------------- Comment By: Hillel (Sabba) Markowitz (sabbahillel) Date: 2001-08-07 06:32 Message: Logged In: YES user_id=286923 The point is that when compiled in 64 bit mode, uint is actually fatal. In order to prevent errors, these "unsigned int" declarations must be changed to "unsigned long". When compiled in 32 bit mode, uint an ulong are the same. However, when compiled in DEC TRU64, or on Solaris 7 or 8 (gcc -m64), there is abinary incompatibility and it is a fatal compilation error not to use unsigned long. -- Said the fox to the fish, "Join me ashore". The fish are the Jews, Torah is our water. Hillel (Sabba) Markowitz sab...@bc..., Sab...@ve... ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2001-08-06 16:40 Message: Logged In: YES user_id=72656 Unfortunately you can't change those procedures because changing size decls would cause binary incompatability in the stubs mechanism. That they are declared as uints might not be optimal, but it is perfectly OK. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110894&aid=443938&group_id=10894 |