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

[no_std] compatibility for standalone crates #313

Closed
jschneider-bensch opened this issue Jun 12, 2024 · 6 comments
Closed

[no_std] compatibility for standalone crates #313

jschneider-bensch opened this issue Jun 12, 2024 · 6 comments
Assignees

Comments

@jschneider-bensch
Copy link
Collaborator

E.g. for libcrux-kem, or in general where possible.

Copy link

This issue has been marked as stale due to a lack of activity for 60 days. If you believe this issue is still relevant, please provide an update or comment to keep it open. Otherwise, it will be closed in 7 days.

@github-actions github-actions bot added the stale label Aug 23, 2024
@franziskuskiefer
Copy link
Member

@jschneider-bensch let's list the crates and what needs to get done.

@github-actions github-actions bot removed the stale label Aug 31, 2024
Copy link

This issue has been marked as stale due to a lack of activity for 60 days. If you believe this issue is still relevant, please provide an update or comment to keep it open. Otherwise, it will be closed in 7 days.

@franziskuskiefer
Copy link
Member

Assigning to @keks as part of the first iteration of a pure Rust libcrux #648.

@keks
Copy link
Member

keks commented Nov 27, 2024

I made most crates no_std in #697. Some didn't work, though:

  • sys/hacl: depends on std::os
  • psq: uses std::time::SystemTime
  • macros: is proc-macro, so shouldn't need to

The PSQ one might be solvable, but I think our chances for sys/hacl are not very good. But since we are already in the way to migrating to hacl-rs, that is temporary.

@franziskuskiefer if you don't have objections, I would close this as resolved.

@franziskuskiefer
Copy link
Member

  • sys/hacl: depends on std::os

As you say, since this is for wrapping C code we don't care for the pure Rust version.

  • psq: uses std::time::SystemTime

Let's not put this in scope for the first pure Rust release and file a separate issue for time not being in core.

  • macros: is proc-macro, so shouldn't need to

Right, this is fine.

Let's file that psq issue and close this.

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

3 participants