search

cil-project / cil

C Intermediate Language
Other
348 stars 86 forks source link

Bytes #42

Open zkincaid opened 6 years ago

pmetzger commented 6 years ago

This is not the first pull request on the project to fix the String/Bytes issue. It appears, though, that no one is currently maintaining the project, and thus it does not appear that integration of one of these pull requests is imminent.

kerneis commented 6 years ago

I really don't have time to work on CIL anymore but I'm happy to add maintainers to the GitHub project if anybody wants to step in. Please let me know. Gabriel

pmetzger commented 6 years ago

I would be able to integrate the pull requests needed to keep it building. I doubt I could do more than that.

michael-schwarz commented 1 year ago

Leaving this here for reference: We (TUM & UTartu) are maintaining a fork of CIL that has many improvements (such as this bytes issue, the switch to Zarith or a dune-based build), including C99 support and support for many C11 features.

https://opam.ocaml.org/packages/goblint-cil/ and https://github.com/goblint/cil

If you can live without MSVC support (which we dropped) and some of the older plugins being removed, it might be worth having a look in the interest of avoiding duplicate work.

pmetzger commented 1 year ago

@michael-schwarz Would you like to simply get commit access to this project?

kerneis commented 1 year ago

I was about to ask the same. CIL is effectively unmaintained and has been so for next to a decade, but is still packaged in some distributions (eg. redhat). If would be nice to get a new upstream if some people still use it. That's how I inherited it in the first place from UCB (using it for my own PhD in Paris).

If you're interested feel free to reach out to me in private @.***) with any question

michael-schwarz commented 1 year ago

Thank you @pmetzger and @kerneis for the offer, and sorry for getting back so late, we discussed this in our group meeting yesterday.

The conclusion that we reached is that it would not be the best course of action to just merge all our changes in here since our fork is not quite a drop-in replacement for this version: Some of our changes are breaking and would require potential users to update their code to work with our fork.

However, we would propose to maybe add a link to our fork to the readme here, so people who are starting a new project or are willing to invest the time needed to switch to our fork are aware of it, and we avoid duplicating work. What do you think?

(And sorry for hijacking your PR Zak :wink:)