warning: comparison of integers of different signs: 'yy_size_t' (aka 'unsigned long') and 'int' [-Wsign-compare]

[ryandesign]

This warning appears when compiling with clang on macOS 14:

post-process/pp_lexer.c:1098:41: warning: comparison of integers of different signs: 'yy_size_t' (aka 'unsigned long') and 'int' [-Wsign-compare]
        if ((yyg->yy_n_chars + number_to_move) > YY_CURRENT_BUFFER_LVALUE->yy_buf_size) {
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[ampli]

In the distributed LG version 5.12.4, the type of yy_buf_size is int. So it seems your build generates it from pp_lexer.l using an old version of flex (or equivalent). Try to install the newer version of flex.

[ryandesign]

Ok, you're right that this depends on which flex is installed. The issue happens when using Apple flex as preinstalled on macOS:

% /usr/bin/flex --version
flex 2.6.4 Apple(flex-34)

and it does not happen when using westes flex as installed by MacPorts:

% /opt/local/bin/flex --version
flex 2.6.4

Apple flex generates code using type yy_size_t whereas westes flex uses type int.

It looks like this bug: https://github.com/westes/flex/issues/118

It seems that Apple has chosen to fix that bug in their flex by changing int to yy_size_t whereas westes has chosen not to fix it.

So I'm not sure if anything needs to be fixed in link-grammar, except for the developers to be aware that this difference exists and to hopefully ensure that the code works with both flex flavors.

[ampli]

It looks like this bug: westes/flex#118

This is another bug, regarding yyleng.

In our case, the problem is with the types of yy_n_chars vs yy_buf_size, which traditionally was yy_size_t (size_t) and got changed to int to avoid the warning.

In our case this bug is not important, as pp_lexer.c parses distributed files (4.0.*knowledge) that cannot be influenced by user input (so yy_n_chars can never become negative due to lines longer than 2GB), and if desired this warning can just be documented in the README.

[linas]

I don't see that there is any change that can be made at the LG end, to fix this.

Enlarging the README seems ... pointless. No one reads README's any more. I'd make a TikTok about it, but my new haircut didn't work out, so I will just close this instead,