Fixes for GCC-14. handle_python_function defined with only one argume…

[fierlo]

resolves #87

Small fixes for GCC-14. Fixes compiled without issue in debian-sid (gcc14, python3.12.6).

Changed type of len from int to long int for pyvar_to_tfvar in tfpython.c, was generating an error.

expr.c call to handle_python_function had error when compiling Python support.

typedef struct Value in command.h has two arguments. Only one provided in expr.c / tfpython.c/h. Updated tfpython.c/h, and added a default/dummy value in call from expr.c.

There's almost definitely a better way to do this, but I don't really know C at all, and this fixed the errors when compiling with the following options:

--enable-atcp --enable-gmcp --enable-option102 --enable-python

[ingwarsw]

I really dont understand why we need that empty argument..

Whats the error without it?

[fierlo]

@ingwarsw

Looking back, it doesn't appear to have been needed. I think I tried to "fix" a compile error by changing something in expr.c first, when I only needed to address the one below in tfpython.c.

When compiling with GCC-14, I got this error:

tfpython.c: In function ‘pyvar_to_tfvar’:
tfpython.c:213:76: error: passing argument 3 of ‘PyBytes_AsStringAndSize’ from incompatible pointer type [-Wincompatible-pointer-types]
213 | if( PyBytes_Check( pRc ) && ( PyBytes_AsStringAndSize( pRc, &cstr, &len ) != -1 ) ) {
| ^~~~
| |
| int *
In file included from /usr/include/python3.12/Python.h:50,
from tfpython.h:6,
from tfpython.c:10:
/usr/include/python3.12/bytesobject.h:57:17: note: expected ‘Py_ssize_t *’ {aka ‘long int *’} but argument is of type ‘int *’
57 | Py_ssize_t len / pointer to length variable or NULL */

Changing int to long int on line 204 compiles without issue.

Like I said in the first one... I really don't know C at all, and was just trying to find something that would compile so that someone who knows better than me might be able to save a slight amount of time. :)

[ingwarsw]

@fierlo Sorry for long delays.. didnt looked here for long time..
But I have a question for the PR.. see comment..

[gary9872]

Thanks for you efforts fiero, I tried compiling from your gcc14 branch, but I still have errors, (first one shown below) Ingwars, I would fix them if I knew how

Cheers,

Gary

command.c: In function ‘handle_localecho_command’: port.h:115:20: error: implicit declaration of function ‘strcasecmp’ [-Wimplicit-function-declaration] 115 | # define cstrcmp strcasecmp | ^~~~~~~~~~ command.c:182:14: note: in expansion of macro ‘cstrcmp’ 182 | else if (cstrcmp(args->data + offset, "on") == 0) local_echo(1);

using

COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues --with-build-config=bootstrap-lto --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.2.1 20240910 (GCC)

python 3.12.7

[fierlo]

Thanks for you efforts fiero, I tried compiling from your gcc14 branch, but I still have errors, (first one shown below) Ingwars, I would fix them if I knew how

Cheers,

Gary

command.c: In function ‘handle_localecho_command’: port.h:115:20: error: implicit declaration of function ‘strcasecmp’ [-Wimplicit-function-declaration] 115 | # define cstrcmp strcasecmp | ^~~~~~~~~~ command.c:182:14: note: in expansion of macro ‘cstrcmp’ 182 | else if (cstrcmp(args->data + offset, "on") == 0) local_echo(1);

using

COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues --with-build-config=bootstrap-lto --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.2.1 20240910 (GCC)

python 3.12.7

If you're compiling on Arch, the default CFLAGs are:

checking ICU_CFLAGS... -std=c11

which means that when you're compiling in Arch, it's checking the code against a different C standard (https://gcc.gnu.org/onlinedocs/gcc/Standards.html).

That is what's generating a lot of the errors. @ingwarsw can likely confirm that my interpretation of the documentation is correct.

If you try to compile without the -std=c11, gcc uses the gnu17 "standard" by default.

[fierlo]

Made a new one because I really don't know how to use Github properly.