Probable Context-Aware Warnings for Floating-Point Equality Comparisons
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 25/100
Direzione di ricerca
Read the issue’s linked Secure Coding Guide section for CWE-664/CWE-197 and review the floating-point equality examples it cites from NeMo and PyTorch. The issue asks whether warnings should be context-dependent, but gives no proposed change or acceptance criteria; done would require agreeing on guidance and updating the relevant guide section to reflect it.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
I am working at OpenRefactory, a static analysis tool company. Our CEO, @openrefactorymunawar previously had some interactions with you and we have been improving our tool by adding the capability to detect some of the bugs that you are describing.
I have a question for one such bug pattern.
Recently, we introduced a fixer that flags warnings when floating-point values are used in equality comparisons. This practice is known to be problematic, as it can lead to unexpected outcomes due to the inherent imprecision of floating-point arithmetic.
The idea for this improvement was inspired by the guidance provided in the
Secure Coding Guide for Python (CWE-664/CWE-197)
Upon running this fixer on various projects, we found a significant number of instances where equality comparisons with floating-point values were being used. For example:
PyTorch 67 instances
NVIDIA Nemo 28 instances
Examples of such occurrences:
This raises a question: Could some of these cases be deliberate on the developers' part, where they knowingly use equality comparisons with floating-point values despite the risks, perhaps for a valid use case? If so, should we raise this warning universally, or should it be more context-dependent?
I'd love to hear your thoughts on this.
- Lingua principale
- Python
- Stelle
- 2
- Fork
- 2
- Merge medio
- 11m
- PR unite (30g)
- 2
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di ossf/python-secure-coding-guide
-
pyscg-0051 should use a context managerForse già presa @s19110 l’ha presa 8 giorni fa. Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
ossf/python-secure-coding-guide#1 · 4 commenti · 1 assegnatario ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 65/100
ossf/python-secure-coding-guide#29 · 1 commento ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
Tutte le issue di ossf/python-secure-coding-guide
Issue simili
-
documentation type/bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
add entry to blockAperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 65/100
StevenBlack/hosts#3299 ·
-
`garak --report` overwrites the input report when its name has no ".report"Forse già presa @0z5a l’ha presa oggi. Apertaneeds-triage
Difficoltà 2/5 Mezza giornata Idoneità per principianti 72/100
I maintainer di solito rispondono entro 2 giorni
-
trace: Pi's 1-hour cache writes are priced at 1.25x, but billed at 2xForse già presa @Shizoqua l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
microsoft/TokenEconomizer#221 ·
I maintainer di solito rispondono entro 1 giorno
-
plot_graph crashes when a mesh node has no m2m edgeForse già presa @tygvi l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
mllam/neural-lam#883 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni