From: <no...@so...> - 2002-02-25 19:02:50
|
Patches item #509340, was opened at 2002-01-27 15:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310894&aid=509340&group_id=10894 Category: 50. Other Tools Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: David Gravereaux (davygrvy) Assigned to: Jeffrey Hobbs (hobbs) Summary: ClientData set to int* not void* Initial Comment: With the MS compiler, the following is allowed without casting even with langauge extensions turned off (-Za). /*#include "tcl.h"*/ #ifdef __STDC__ # if defined(__STDC_VERSION__) && __STDC_VERSION__ == 199409L # pragma message ("*** ISO C and AM1 complient") # else # pragma message ("*** ISO C, but not AM1 complient") # endif #else # pragma message ("*** Not ISO C complient") #endif void main (void) { /*ClientData someTypeLessPointer;*/ void *someTypeLessPointer; struct { __int64 a; char b; } someStruct; someTypeLessPointer = &someStruct; } Placing a typed pointer into a typeless pointer is allowed. The typedef for ClientData should be void*, not int* under this compiler, IMO. Notice the test for __STDC__ is a failure under this compiler, too. __STDC__ is only defined when the -Za switch is used. I'm at a loss to understand what the complience of the compiler really is, but getting back to the patch, a void* is legal, so let's use it. ---------------------------------------------------------------------- >Comment By: Jeffrey Hobbs (hobbs) Date: 2002-02-25 11:02 Message: Logged In: YES user_id=72656 I fail to see a problem stated. If it ain't broke, don't fix it. Unless there is a clear problem with the current source, let's not change things. ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2002-02-22 23:53 Message: Logged In: YES user_id=7549 forget "some systems". This is Win32 with MSVC as the compiler. What is that test asking? Is it asking are you strict ANSI or ANSI compilent as oppossed to pre-ANSI? #ifndef _CLIENTDATA # if defined(__STDC__) || defined(__cplusplus) || defined (__BORLANDC__) typedef void *ClientData; # else typedef int *ClientData; # endif /* __STDC__ */ # define _CLIENTDATA #endif More flexible? How so? sizeof(*(ClientData))? What good is that, not that it would work? I do most of my work in C++ and never had to cast a typed pointer to a ClientData. Coming out of a ClientData to a typed pointer, of course yes, I had to cast. Then I do some work in C, and I get this damn cast shit going into a ClientData. But its still legal in C. Typed pointer to a void pointer without a cast is legal in this compiler for C. If this is the case, and is fine in C++ according to the existing logic, don't force an int* when it isn't needed, please. There are users of the Tcl API besides the core itself where old-fashioned seems to always take precidence over advances. Just because its there, and has been for a while, doesn't mean its right by only it's existence. Please question the meaning of the preprocessor logic. It doesn't make sense for this compiler. #if !defined(__STDC__) and !defined(__cplusplus) == 1 does that mean a void* isn't legal? But in the case for defined(_MSC_VER), it is true, though. Is that test testing a compiler feature or forcing an interface? If it's forcing an interface, why? It gets in my way as a user of the API. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-02-22 23:04 Message: Logged In: YES user_id=72656 I'm not sure that I see this is really a problem in the sources though ... also int* gives more flexibility than void* on some systems. ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2002-01-27 16:07 Message: Logged In: YES user_id=7549 In this case, I guess "not ISO C" means greater than instead of "sub ISO C" ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310894&aid=509340&group_id=10894 |