Expose the unique identifier from Type objects
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Ambito
- api, reverse-engineering
Direzione di ricerca
Start with the TypeContainer module documentation and the existing TypeContainer.get_type_id(name) entry point, then inspect how Type objects represent unnamed types. Done means an unnamed Type exposes a stable unique identifier that can be used to match it outside its original TypeContainer; clarify the supported hashing behavior as part of the API design.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
What is the feature you'd like to have?
TypeContainer module documentation says:
Types are stored with both a unique id and a unique name.
This phrasing is inaccurate, as
- some types have no names
- I can't see a way to get the ID of a
Typeif it has no name.
I'd expect Type to expose an ID but it doesn't, instead I think I'm supposed to use TypeContainer.get_type_id(name). But I can't do that, because I can't provide a name for unnamed types.
I think Types should simply expose their unique ID so unnamed types can be tracked outside their TypeContainer.
Is your feature request related to a problem?
Suppose I preprocess Types from a TypeContainer without modifying TypeContainer. Then I want to match a preprocessed, unnamed type to a symbol of the original unnamed type. Since the type has no name, I can't look it up by that property and I can't get its ID. The only solution I found is to map the original Type to the preprocessed one (Type is hashable), then use this extra index to look up preprocessed types, but I'm not sure if this is reliable/supported.
Some code may clear things up:
for t in all_types: # all_types may contain unnamed types
processed=process(t)
store_for_me(processed)
my_types[t]=processed # Extra index for matching, will this behave as I expect?
for s in all_symbols:
sym_data_type=bv.data_vars[s.address].type
# I'd like to do something like retrieve_for_me(sym_data_type.id)
my_type_for_sym=my_types[sym_data_type]
(My more specific use case is this project)
Are any alternative solutions acceptable?
The most convenient solution for me as a user would be if every type had a unique name (even an auto-generated one), but I'm not sure if this would violate the design of the type system.
Additional Information:
N/A
- Lingua principale
- C++
- Stelle
- 1.3k
- Fork
- 298
- Merge medio
- 5g 5h
- PR unite (30g)
- 19
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
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 Vector35/binaryninja-api
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 88/100
Vector35/binaryninja-api#8540 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
Vector35/binaryninja-api#8516 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
Vector35/binaryninja-api#8503 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
Vector35/binaryninja-api#8446 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
Vector35/binaryninja-api#8444 ·
Tutte le issue di Vector35/binaryninja-api
Issue simili
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 92/100
autowarefoundation/autoware_universe#13413 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
-
automated-analysis bug memory-safety
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
-
Sensor initialization takes very long when `--initial-sim-time` is set to current UNIX timestamp Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
gazebosim/gz-sensors#662 · 1 commento ·