An incompatible-pointer-types in pTk/Xlib.t that induces an error with gcc 14

[cessenat]

In file pTk/Xlib.t line 334 there is
VFUNC(KeySym,XKeycodeToKeysym,V_XKeycodeToKeysym,_ANSI_ARGS_((Display *, unsigned int, int)))
which, at compile time, induces with gcc 11.3 on Ubuntu 22.04

x86_64-linux-gnu-gcc -c  -I..  -I. -Ibitmaps  -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g   -DVERSION=\"804.036\" -DXS_VERSION=\"804.036\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.34/CORE"    Xlib_f.c
In file included from Xlib_f.c:17:
Xlib.t:334:1: warning: ‘XKeycodeToKeysym’ is deprecated [-Wdeprecated-declarations]
  334 | VFUNC(KeySym,XKeycodeToKeysym,V_XKeycodeToKeysym,_ANSI_ARGS_((Display *, unsigned int, int)))
      | ^~~~~
In file included from Xlib_f.c:4:
/usr/include/X11/Xlib.h:1687:15: note: declared here
 1687 | extern KeySym XKeycodeToKeysym(
      |               ^~~~~~~~~~~~~~~~
Xlib.t:334:14: warning: initialization of ‘KeySym (*)(Display *, unsigned int,  int)’ {aka ‘long unsigned int (*)(Display *, unsigned int,  int)’} from incompatible pointer type ‘KeySym (*)(Display *, KeyCode,  int)’ {aka ‘long unsigned int (*)(Display *, unsigned char,  int)’} [-Wincompatible-pointer-types]
  334 | VFUNC(KeySym,XKeycodeToKeysym,V_XKeycodeToKeysym,_ANSI_ARGS_((Display *, unsigned int, int)))
      |              ^~~~~~~~~~~~~~~~

while with gcc 14.1 on Fedora 40 the warning is now en error.

Therefore I would suggest to write instead
VFUNC(KeySym,XKeycodeToKeysym,V_XKeycodeToKeysym,_ANSI_ARGS_((Display *, unsigned char, int)))
to correct that.
What do you think @eserte ? Thanks.

[eserte]

Theoretically yes. However, Xlib.t seems to be generated somehow, using the script pTk/mkVFunc it seems, and I have to figure out how this is supposed to work.

[eserte]

Probably the change needs to be made in pTk/Xlib.h. pTk/Xlib.t will be generated from it.

[wlmb]

I have a similar problem with gcc 14.2, I can't 'make'. Any suggestion?

[wlmb]

The error I get is
cc -c -I/usr/include/freetype2 -I.. -I/usr/include/freetype2 -I. -Ibitmaps -I/usr/include/freetype2 -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -DVERSION="804.036" -DXS_VERSION="804.036" -fPIC "-I/home/mochan/perl5/perlbrew/perls/perl-5.36.0/lib/5.36.0/x86_64-linux/CORE" tkCanvText.ctkCanvText.c: In function ‘GetTextIndex’:
tkCanvText.c:1253:40: error: passing argument 2 of ‘TcldeclsVptr->V_Tcl_GetStringFromObj’ from incompatible pointer type [-Wincompatible-pointer-types]
1253 | string = Tcl_GetStringFromObj(obj, &length);
| ^~~~~~~
| |
| size_t * {aka long unsigned int *}
tkCanvText.c:1253:40: note: expected ‘int *’ but argument is of type ‘size_t *’ {aka ‘long unsigned int *’}

[cessenat]

-Wincompatible-pointer-types

For that specific issue you can try to compile with the GCC compiler option
-Wincompatible-pointer-types

[wlmb]

Didn't help :(

[Tux]

Chicken out: add -Wno-error=incompatible-pointer-types to the CCFLAGS definitions in Makefile and pTk/Makefile.
It is still wrong, but now there is no need to revert to gcc-13 or dig into the errors yourself

[Leont]

In file pTk/Xlib.t line 334 there is VFUNC(KeySym,XKeycodeToKeysym,V_XKeycodeToKeysym,_ANSI_ARGS_((Display *, unsigned int, int))) which, at compile time, induces with gcc 11.3 on Ubuntu 22.04

x86_64-linux-gnu-gcc -c  -I..  -I. -Ibitmaps  -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g   -DVERSION=\"804.036\" -DXS_VERSION=\"804.036\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.34/CORE"    Xlib_f.c
In file included from Xlib_f.c:17:
Xlib.t:334:1: warning: ‘XKeycodeToKeysym’ is deprecated [-Wdeprecated-declarations]
  334 | VFUNC(KeySym,XKeycodeToKeysym,V_XKeycodeToKeysym,_ANSI_ARGS_((Display *, unsigned int, int)))
      | ^~~~~
In file included from Xlib_f.c:4:
/usr/include/X11/Xlib.h:1687:15: note: declared here
 1687 | extern KeySym XKeycodeToKeysym(
      |               ^~~~~~~~~~~~~~~~
Xlib.t:334:14: warning: initialization of ‘KeySym (*)(Display *, unsigned int,  int)’ {aka ‘long unsigned int (*)(Display *, unsigned int,  int)’} from incompatible pointer type ‘KeySym (*)(Display *, KeyCode,  int)’ {aka ‘long unsigned int (*)(Display *, unsigned char,  int)’} [-Wincompatible-pointer-types]
  334 | VFUNC(KeySym,XKeycodeToKeysym,V_XKeycodeToKeysym,_ANSI_ARGS_((Display *, unsigned int, int)))
      |              ^~~~~~~~~~~~~~~~

while with gcc 14.1 on Fedora 40 the warning is now en error.

Therefore I would suggest to write instead VFUNC(KeySym,XKeycodeToKeysym,V_XKeycodeToKeysym,_ANSI_ARGS_((Display *, unsigned char, int))) to correct that. What do you think @eserte ? Thanks.

That should be solved by the following patch:

diff --git pTk/Xlib.t pTk/Xlib.t
index a193fc5..c90964c 100644
--- pTk/Xlib.t
+++ pTk/Xlib.t
@@ -331,7 +331,7 @@ VFUNC(int,XIntersectRegion,V_XIntersectRegion,_ANSI_ARGS_((Region, Region, Regio
 #endif /* !DO_X_EXCLUDE */
 
 #ifndef XKeycodeToKeysym
-VFUNC(KeySym,XKeycodeToKeysym,V_XKeycodeToKeysym,_ANSI_ARGS_((Display *, unsigned int, int)))
+VFUNC(KeySym,XKeycodeToKeysym,V_XKeycodeToKeysym,_ANSI_ARGS_((Display *, KeyCode, int)))
 #endif /* #ifndef XKeycodeToKeysym */
 
 #ifndef XKeysymToString

The error I get is cc -c -I/usr/include/freetype2 -I.. -I/usr/include/freetype2 -I. -Ibitmaps -I/usr/include/freetype2 -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -DVERSION="804.036" -DXS_VERSION="804.036" -fPIC "-I/home/mochan/perl5/perlbrew/perls/perl-5.36.0/lib/5.36.0/x86_64-linux/CORE" tkCanvText.ctkCanvText.c: In function ‘GetTextIndex’: tkCanvText.c:1253:40: error: passing argument 2 of ‘TcldeclsVptr->V_Tcl_GetStringFromObj’ from incompatible pointer type [-Wincompatible-pointer-types] 1253 | string = Tcl_GetStringFromObj(obj, &length); | ^~~~~~~ | | | size_t * {aka long unsigned int *} tkCanvText.c:1253:40: note: expected ‘int *’ but argument is of type ‘size_t *’ {aka ‘long unsigned int *’}

That should be solved by

diff --git pTk/tkCanvText.c pTk/tkCanvText.c
index 1a6919a..5ccb0c3 100644
--- pTk/tkCanvText.c
+++ pTk/tkCanvText.c
@@ -1234,7 +1234,7 @@ GetTextIndex(interp, canvas, itemPtr, obj, indexPtr)
                 * index. */
 {
     TextItem *textPtr = (TextItem *) itemPtr;
-    size_t length;
+    int length;
     int c;
     TkCanvas *canvasPtr = (TkCanvas *) canvas;
     Tk_CanvasTextInfo *textInfoPtr = textPtr->textInfoPtr;

There are some more issues left after than, because it's sloppy with types all over the place, and a few because it is still using pre-ANSI style arguments in some places. The entire codebase needs to be lifted to 90s standards at least.

[bulk88]

That should be solved by

diff --git pTk/tkCanvText.c pTk/tkCanvText.c
index 1a6919a..5ccb0c3 100644
--- pTk/tkCanvText.c
+++ pTk/tkCanvText.c
@@ -1234,7 +1234,7 @@ GetTextIndex(interp, canvas, itemPtr, obj, indexPtr)
     TextItem *textPtr = (TextItem *) itemPtr;
-    size_t length;
+    int length;
     int c;
     TkCanvas *canvasPtr = (TkCanvas *) canvas;

There are some more issues left after than, because it's sloppy with types all over the place, and a few because it is still using pre-ANSI style arguments in some places. The entire codebase needs to be lifted to 90s standards at least.

Ignoring Intel 286s/Crays/household MW ovens, size_t is an unsigned ptr sized num on all OSes/all CCs/all CPUs. int? Who knows what that type is and where. Win64 says int is 32bit on a 64b CPU, Linux/Unixes say int is 64b on a 64b CPU. Using GCC on any 32b CPU? 50/50 chance someone turned on GCC's global command line flag to make "int 32->64", sort of like Perl's "64b IVs on 32b CPU" build config. int is signed, if it gets promoted to a larger integer type, it gets sign extension (oh no!), not uneventful boring zero extension (all unsigned types).

The size_t length; was probably correct, the int needs very very specific technical justification on why to use it. One example, would be

• we use [32b] ints for performance b/c they are 32b types, and REX prefix on every 64bit aware CPU opcode to do 64bit arthmitic on AMD64 is expensive, hence we prefer U8/U32/int on 64b CPUs vs size_t math."

[Leont]

The size_t length; was probably correct, the int needs very very specific technical justification on why to use it. One example, would be

The reason here would be "we're using it with a sloppy Tcl API". I agree it shouldn't ask for an int, but it does so we should comply.

[mtelka]

What about to do this instead?

--- Tk-804.036/pTk/mTk/generic/tkCanvText.c.orig
+++ Tk-804.036/pTk/mTk/generic/tkCanvText.c
@@ -1250,7 +1250,7 @@
        goto doxy;
     }
 
-    string = Tcl_GetStringFromObj(obj, &length);
+    string = Tcl_GetStringFromObj(obj, NULL);
     c = string[0];
     length = strlen(string);
 

The length is overwritten two lines down so it is basically not needed to be passed to Tcl_GetStringFromObj().