kermit @9.0.302: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]

[SaintBol]

minicom dependencies include kermit. kermit doesn't compile on Sequoia. Same kind of issue than for other packages with Sequoia (log attached):

:info:build ckwart.c:531:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
:info:build   531 | main(argc,argv) int argc; char **argv; {
:info:build       | ^
:info:build       | int

But whatever: kermit-devel (10.0-beta09 compiles on Sequoia. Therefore it's probably useless to try to fix the current (old 9.0.302) kermit package: the kermit package should probably just be updated to 10.0-beta09 (the kermit-devel package).

[SaintBol]

main.log compilation error log

[SaintBol]

By the way, the update ticket #71132 suggested to update the kermit package. However this was an update ticket, whereas this one is a defect ticket.

[ryandesign (Ryan Carsten Schmidt)]

The port should not be updated to version 10 because so far that is only a beta version. The port is already using the latest stable version, 9.0.302; we should fix that so that it will compile, if the developers will not do so.

[ryandesign (Ryan Carsten Schmidt)]

If nobody has done so yet, someone should file a bug report with the developers of kermit to ask them to release a stable version that does not have this bug.

[shpokas]

Pardon my ignorance but why can't this issue be solved like this comment:ticket:70755:11 instead of going back to developers of kermit?

[fabianwenk (Fabian Wenk)]

What is against using the latest beta version, if this would solve the building issue?
FreeBSD Ports are also using it, since a while already: ​https://cgit.freebsd.org/ports/log/comms/kermit

As I am not using kermit on FreeBSD and have not used it on macOS since a while (or I should better say not used minicom, which was still installed), I can not comment on stability. But according to FreeBSD bug reports, nobody complained anything yet: ​https://bugs.freebsd.org/bugzilla/buglist.cgi?order=Importance&query_format=advanced&short_desc=comms%2Fkermit&short_desc_type=allwordssubstr

I am even not sure if the Manhattan (Prolific based) USB-A/Serial adapter may still work (needs kernel extensions), which I would use with minicom for some devices serial consoles. I even think that for my use case I do not need kermit at all, but it is a hard dependency for minicom on MacPorts (not on FreeBSD Ports).

[tmcintos]

I also encountered this problem via the minicom dependency while attempting to migrate my MacPorts to macOS 15.x.

Why not just add the -Wno-implicit-int option (assuming that fixes this) as suggested above and get this going?

Thanks, Tim

[ryandesign (Ryan Carsten Schmidt)]

Replying to shpokas:

Pardon my ignorance but why can't this issue be solved like this comment:ticket:70755:11 instead of going back to developers of kermit?

That ticket worked around the problem in that port by downgrading the errors back to warnings again. But compiler makers deliberately upgraded these warnings to errors in recent years because they are bad programming practices, already disallowed by the 1999 version of the C standard over a quarter century ago. Future compilers might not allow this error to be downgraded. The best solution is to fix the code. The people to do that are the developers of the software so the problem needs to be reported to them so that they can do that and release a fixed stable version.

[ryandesign (Ryan Carsten Schmidt)]

Replying to fabianwenk:

What is against using the latest beta version, if this would solve the building issue?

​According to Wikipedia beta software "is feature-complete but likely to contain several known or unknown bugs". It is specifically not designated as stable. MacPorts users expect to receive stable software unless they request otherwise by installing a -devel port.

[SaintBol]

Replying to ryandesign:

According to Wikipedia beta software "is feature-complete but likely to contain several known or unknown bugs". It is specifically not designated as stable. MacPorts users expect to receive stable software unless they request otherwise by installing a -devel port.

In one hand we have a software version that achieved perfect stability, as it can not even be started anymore (as it cannot be compiled). In the other hand we have a software version that seems to work, whatever its release number. MacPorts users expect to receive software that can be started (I suppose).

[dwhitla (Jade Whitla)]

I also encountered this problem via the minicom dependency while attempting to migrate my MacPorts to macOS 15.x. Is anything happening on this?

[tmcintos]

Replying to ryandesign:

Replying to shpokas:

Pardon my ignorance but why can't this issue be solved like this comment:ticket:70755:11 instead of going back to developers of kermit?

That ticket worked around the problem in that port by downgrading the errors back to warnings again.

... which is exactly what is needed right now to get people up and going.

But compiler makers deliberately upgraded these warnings to errors in recent years because they are bad programming practices, already disallowed by the 1999 version of the C standard over a quarter century ago. Future compilers might not allow this error to be downgraded. The best solution is to fix the code. The people to do that are the developers of the software so the problem needs to be reported to them so that they can do that and release a fixed stable version.

Sorry, but this is irrelevant. None of this matters when you have users down and you have a perfectly workable solution in-hand.

The focus should be on the users here. What we need right now is to fix this regression. It doesn't have to be the best solution. You can work on that after the immediate problem is fixed.

There is a ton of legacy C code in the world that is not going anywhere anytime soon, so I'd be very surprised to see K&R support yanked from compilers in the near future. At least it seems like a pretty dumb idea to me. It makes sense to discourage people from writing new K&R style C code by making this an error by default, but arguing that 30+ year-old stable code must be rewritten for no other reason than to update the style is dumb.

[DarwinNE (Davide Bucci)]

If it can work as a quick and dirty workaround, I managed to compile Kermit by manually patching the file that creates the issue.

In my install, it is locally stored as: /System/Volumes/Data/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_comms_kermit/kermit/work/cku302/ckwart.c

If it is not there, I found the file with a simple "find":

sudo find / -name ckwart.c 2>/dev/null

I added "int " at the beginning of the line 531, that is at the origin of the error. The corrected line now is:

int main(argc,argv) int argc; char **argv; {

The next sudo port install kermit does not download again the sources, so the patched version is used.

I know this is not a proper way to solve the issue, but it was important for me to find a quick solution to continue using minicom.

BTW, I noticed a comment in the file:

/*
  If you get complaints about "main: return type is not blah",
  define MAINTYPE on the CC command line, e.g. "CFLAGS=-DMAINTYPE=int".
*/

Maybe this is something that can be managed at the port level, without changing the source files.

I hope it helps.

[Parakleta]

It is pretty clear that the ckwart.c file's conditional defines are broken (looks like a patch merge error). Looking from lines 496:530 it is clear that no return type can be specified if STRATUS is defined, but then the ifdef __GNUC__ test which should give us the correct value is behind a ifdef STRATUS (thus putting us in the impossible condition that STRATUS must both be defined and not defined at the same time).

If we did somehow get into that clause we would actually end up with int int main(argc,argv) which is also clearly wrong.

The best option would be to update to a later version. The last "release" was 14 years ago despite continuous development since then of both the v9 and v10 versions - I think the alpha/beta flags are being used more as a legal disclaimer than an actual indication of quality. This particular bug was fixed in C-Kermit 9.0.305 Alpha.02 19 September 2020.

If the decision is not to update then at the very least, building on DarwinNE's suggestion, the build arguments/environment should have KFLAGS=-DMAINTYPE=int set in the build process. This would be done by adding the following line to the Portfile:

build.env-append KFLAGS=-DMAINTYPE=int