Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some fixes for modern Arch Linux, bison and gcc 14 #51

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

andi8086
Copy link

Here are some suggestions to make it work on modern Linux with:

  • bison 3.8.2
  • gcc 14.1.1

There are two fixes regarding gcc 14.1.1:

  • main function of lcc must be of return type 'int'
  • yylexx() must be declarated in .y otherwise gcc 14 bails out with 'implicit function declaration'

I included an example build script for linux since this was not so straight forward for me to understand, how to compile it.
It also takes care of using "bison" instead of "bison -y" because "bison -y" gives warnings about not supporting "%term".

Furthermore, gram.c is generated and should hence not be in the git.

Andreas J. Reichel and others added 3 commits May 28, 2024 20:56
'bison -y' is default emulation for yacc on linux and
this spits out warnings that %term is not supported.
So don't use emulation mode of yacc but bison instead.

Default output file is bison.gram.c, set it to y.gram.c

Signed-off-by: Andreas J. Reichel <[email protected]>
main is supposed to be 'int'

Signed-off-by: Andreas J. Reichel <[email protected]>
gram.c is generated by BISON and should not be in the source
tree.

Signed-off-by: Andreas J. Reichel <[email protected]>
@bret-walda
Copy link

Its a C89 compiler that was built with C89 standard so shouldn't this be compiled with std=gnu89 or -ansi instead of adding the int return type to main.

@andi8086
Copy link
Author

andi8086 commented Feb 4, 2025 via email

@bret-walda
Copy link

I am just asking here but if i already have a compiled version of lcc and try to bootstrap it wouldn't this cause issues with the int being explicit now or am i just being dense i have tried to compile some older programs that used this and they wouldn't compile unless i added the gnu89 flag. The compiler says it is C89 compliant shouldn't the compiler also adhere to it and be built using the standard. I am just trying to understand the thought process here. Thanks in advance for bearing with me.

@rofl0r
Copy link

rofl0r commented Feb 5, 2025

wouldn't this cause issues with the int being explicit now

no, that's fine in both C89 and newer standards. so using the version that works with any seems preferable. though having watched this repo for the past decade filing a PR here is a waste of time if one wants to get it merged...

@bret-walda
Copy link

wouldn't this cause issues with the int being explicit now

no, that's fine in both C89 and newer standards. so using the version that works with any seems preferable. though having watched this repo for the past decade filing a PR here is a waste of time if one wants to get it merged...

So i must be confusing C89 with K&R version and thanks for clearing up the confusion. Yup figured since it is also tied to their book and they might be happy with how far it has come and don't want to update it anymore but you have been watching this repo for the past decade must be the OG cracked c programmer.

@rofl0r
Copy link

rofl0r commented Feb 5, 2025

but you have been watching this repo for the past decade must be the OG cracked c programmer.

it's more a matter of clicking the watch repo button here on github to get notified of anything happening here...

@andi8086
Copy link
Author

andi8086 commented Feb 5, 2025 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants