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

clightgen should produce configuration information #226

Closed
andrew-appel opened this issue Apr 2, 2018 · 4 comments
Closed

clightgen should produce configuration information #226

andrew-appel opened this issue Apr 2, 2018 · 4 comments

Comments

@andrew-appel
Copy link

It would be very useful if clightgen, compiling foo.c into foo.v, would record information about the configuration, in particular,

(1) the following information from Makefile.config
ARCH, BITSIZE, ENDIANNESS

(2) version of CompCert
Version number (e.g., 3.2)
Git commit number

(3) the following information from command-line arguments
filename (e.g., foo.c)
-normalize (true or false)

(4) date/time that clightgen was run

This information should be in a Coq structure, not in a comment, so that tools that import foo.v can query it directly.

Why would this be useful? If the configuration of CompCert does not match the configuration of another tool such as VST, then the foo.v file will be subtly incompatible, causing difficult-to-diagnose bugs. This explicit configuration information will make the diagnosis easy.

@xavierleroy
Copy link
Contributor

I see no one followed up on this suggestion; sorry about that. Globally it looks good. However:

(2) Git commit number

This is notoriously hard to include in a program, see e.g. https://stackoverflow.com/questions/3442874/in-git-how-can-i-write-the-current-commit-hash-to-a-file-in-the-same-commit

(4) date/time that clightgen was run

Timestamps have little value and prevent reproducible builds.

@xavierleroy
Copy link
Contributor

See proposal at #238. Please review.

@andrew-appel
Copy link
Author

Looks good. Thank you.

@xavierleroy
Copy link
Contributor

Thanks for the review. It's merged.

xavierleroy added a commit that referenced this issue Mar 2, 2020
According to ISO C, `free(NULL)` is correct and does nothing.
This commit updates accordingly the formal semantics of the `free`
external function and the reference interpreter.

Closes: #334
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

No branches or pull requests

2 participants