Skip to content

Add new templates for issues#28

Closed
jaisnan wants to merge 1 commit into
model-checking:mainfrom
jaisnan:add-generic-maintainence-templates
Closed

Add new templates for issues#28
jaisnan wants to merge 1 commit into
model-checking:mainfrom
jaisnan:add-generic-maintainence-templates

Conversation

@jaisnan

@jaisnan jaisnan commented Jun 27, 2024

Copy link
Copy Markdown

With the new template for tracking issues, there is no path for users to create issues for maintainence of generic issues. These templates allow users to create issues that are maintainence related or generic in nature.

Call-out:

  1. Need templates in the future for tool applications and challenge proposals?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

@jaisnan jaisnan requested a review from a team as a code owner June 27, 2024 00:19
@@ -0,0 +1,10 @@
---
name: Generic Issue

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generic is not needed.

---
name: Maintenance Task
about: For repository upkeep and improvements
title: '[MAINTENANCE] '

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

trailing space

@@ -0,0 +1,14 @@
---
name: Maintenance Task
about: For repository upkeep and improvements

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i would not say improvements.

labels: Maintenance
---

[Briefly describe the maintenance task]

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is inconsistent with the previous ones.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't the create from blank issue enough?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

@jaisnan jaisnan closed this Jul 30, 2024
MavenRain added a commit to MavenRain/verify-rust-std that referenced this pull request Jun 16, 2026
  Add Kani proof harnesses establishing the memory safety of all 12
  safe-functions-with-unsafe-bodies in core::num::flt2dec: the 6 formatting
  entry points (flt2dec/mod.rs) and the 6 Grisu/Dragon strategy functions
  (flt2dec/strategy/{grisu,dragon}.rs).

  Each unsafe block (MaybeUninit::assume_init_* and slice indexing) is proven
  to touch only initialized, in-bounds memory. The bignum/Fp arithmetic is
  abstracted via sound stubbing -- buffer safety is independent of the numeric
  values, and value inspection (cmp/is_zero) is made nondeterministic so all
  control-flow paths are explored.

  The shortest-mode functions (grisu::format_shortest_opt,
  dragon::format_shortest)
  have an implicit loop bound; their digit index is bounded by the Grisu/Loitsch
  digit-count theorem (a 53-bit-precision f64 has <= MAX_SIG_DIGITS = 17
  significant decimal digits), cited as a cfg(kani) assume because CBMC cannot
  derive it from the unwound arithmetic. The harnesses use the tight decode()
  precondition (the functions are internal and only ever receive a decode()
  result for a real f64), which is what makes that assume sound.

  All added annotations are cfg(kani) verification-only and compile out of normal
  builds. Harnesses require -C debug-assertions=off.

Signed-off-by: Onyeka Obi <softwareengineerasaservant@isurvivable.cv>
MavenRain added a commit to MavenRain/verify-rust-std that referenced this pull request Jun 16, 2026
…ition-2 OOM)

  - Remove concrete dragon::check_format_exact: full unstubbed bignum (unwind 50)
    exhausted CBMC memory in the verify-std partition (ran ~6h, cancelled).
    format_exact buffer safety is already proven by check_format_exact_stub.
  - Run autoharness with debug-assertions off: the flt2dec harnesses stub the
    bignum/Fp arithmetic, making std debug_assert! digit-correctness checks
    (d<10, mant<scale) unprovable. Those are not memory-safety properties and are
    already dead in the verify-std job (--prove-safety-only). Keeps the two jobs
    consistent; monotonic (only removes checks).

Signed-off-by: Onyeka Obi <softwareengineerasaservant@isurvivable.cv>
MavenRain added a commit to MavenRain/verify-rust-std that referenced this pull request Jun 17, 2026
…ition-2 OOM)

  - Remove concrete dragon::check_format_exact: full unstubbed bignum (unwind 50)
    exhausted CBMC memory in the verify-std partition (ran ~6h, cancelled).
    format_exact buffer safety is already proven by check_format_exact_stub.
  - Run autoharness with debug-assertions off: the flt2dec harnesses stub the
    bignum/Fp arithmetic, making std debug_assert! digit-correctness checks
    (d<10, mant<scale) unprovable. Those are not memory-safety properties and are
    already dead in the verify-std job (--prove-safety-only). Keeps the two jobs
    consistent; monotonic (only removes checks).

Signed-off-by: Onyeka Obi <softwareengineerasaservant@isurvivable.cv>
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