#4226 compile warning for tclBasic.c

obsolete: 8.6a4
closed-fixed
6
2011-04-12
2008-12-17
No

platform: sun sparc solaris 8, sun c compiler, tcl 8.6 cvs head

During the gmake all step, the following warning is produced:

/vol/tclsrcsol/tcl86/tcl/unix/../generic/tclAsync.c
/opt/SUNWspro/bin/cc -c -g -KPIC -I"." -I/vol/tclsrcsol/tcl86/tcl/unix/../unix -I/vol/tclsrcsol/tcl86/tcl/unix/../generic -I/vol/tclsrcsol/tcl86/tcl/unix/../
libtommath -DPACKAGE_NAME=\"tcl\" -DPACKAGE_TARNAME=\"tcl\" -DPACKAGE_VERSION=\"
8.6\" -DPACKAGE_STRING=\"tcl\ 8.6\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DTCL_CFGVAL_ENCODING=\"iso8859-1\" -D_REENTRANT=1
-D_POSIX_PTHREAD_SEMANTICS=1 -DTCL_SHLIB_EXT=\".so\" -DTCL_CFG_DEBUG=1 -DTCL_TOMMATH=1 -DMP_PREC=4 -DTCL_WIDE_INT_TYPE=long\ long -DHAVE_STRUCT_DIRENT64=1 -DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1 -DHAVE_TYPE_OFF64_T=1 -DWORDS_BIGENDIAN=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRTOL=1 -DHAVE_WAITPID=1 -
DHAVE_GETADDRINFO=1 -DUSE_TERMIOS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -
DHAVE_DECL_TZNAME=1 -DHAVE_TZNAME=1 -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 -DHAVE_MKTIME=1 -DHAVE_TIMEZONE_VAR=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DNO_UNION_WAIT=1 -DHAVE_SIGNED_CHAR=1
-DHAVE_LANGINFO=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_FILIO_H=1 -DTCL_UNLOAD_DLLS=1
/vol/tclsrcsol/tcl86/tcl/unix/../generic/tclBasic.c
"/vol/tclsrcsol/tcl86/tcl/unix/../generic/tclBasic.c", line 4297: warning: assignment type mismatch:
pointer to function(pointer to void, pointer to struct Tcl_Interp {pointer to char unused3, pointer to function(..) returning void unused4, int unused5}
, int, pointer to const pointer to struct Tcl_Obj {int refCount, pointer to char
bytes, int length, pointer to const struct Tcl_ObjType {..} typePtr, union {..
} internalRep}) returning int "=" pointer to void

While I understand it is "just" a warning, I thought it might be worthwhile hearing about in case there is something that can be done about it.

Discussion

  • Don Porter

    Don Porter - 2008-12-17
    • labels: 105687 --> 45. Parsing and Eval
    • assigned_to: mdejong --> dgp
     
  • Don Porter

    Don Porter - 2008-12-17
    • assigned_to: dgp --> dkf
     
  • Don Porter

    Don Porter - 2008-12-17

    best to add a typecast?

     
  • Donal K. Fellows

    Problem is, C doesn't guarantee that sizeof(void*)==sizeof(Tcl_ObjCmdProc*) for various reasons. (If they are the same, it's a safe thing to do. If they aren't, it's disastrous.)

    So, a cast and an assert. (Assigning to originator of this code.)

     
  • Donal K. Fellows

    • assigned_to: dkf --> msofer
     
  • Alexandre Ferrieux

    Donal, can you give a pointer (pun intended) to a relevant standard excerpt showing this unbelievable degree of freedom ? Or details about the "various reasons" ?

     
  • Donal K. Fellows

    I just googled (and relied on memory and kbk and jenglish)

     
  • Kevin B KENNY

    Kevin B KENNY - 2008-12-17

    Possible fix attached, should have near zero performance impact since it's just moving code. Test suite passes with the patch applied. I don't claim to know about all the implications of delaying the fetch of objProc and clientData.
    File Added: 2440625.patch

     
  • Kevin B KENNY

    Kevin B KENNY - 2008-12-17
     
  • miguel sofer

    miguel sofer - 2009-05-01
    • priority: 5 --> 6
     
  • miguel sofer

    miguel sofer - 2011-04-12
    • assigned_to: msofer --> kennykb
     
  • miguel sofer

    miguel sofer - 2011-04-12

    Patch adapted to trunk and committed

     
  • miguel sofer

    miguel sofer - 2011-04-12
    • status: open --> closed-fixed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks