Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Alternative map sorting

Aperta
  • Qualcosa non va?
#173 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
c
Ambito
embedded-iot

Direzione di ricerca

Inizia da cborvalidation.c intorno alla riga 475 e rivedi i flag esistenti per l’ordinamento delle mappe e l’unicità. Chiarisci se l’ordinamento alternativo debba sostituire o integrare il comportamento attuale, quindi definisci l’ordine previsto, la gestione delle chiavi e il comportamento in caso di chiavi duplicate; il completamento dipende dall’accordo sul design e sull’ambito dell’implementazione.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Hello,

I've been looking into the CBOR validator and how maps are considered as sorted or not. In another project, I have previously been using another serialization standard that strictly defines maps in another way. Such as keys must only be strings, keys must be stored in lexicographical order and that no duplicates are allowed. Now we are looking into changing to cbor.

The CBOR specification does not strictly specifies what an ordered map is, but recommends that they should also be sorted in length. Meaning that "aa" > "b".

The alternatives are:

  • Change sorting specification in our protocol (to order the fields like CBOR specification recommends)
  • Not having sorted maps
  • Finding/adapting a cbor library to allow for alternative sorting

Sorting is nice since is allows for linear parsing. Since we rely on this, we cannot directly swap to cbor. I would like to start a discussion of supporting an alternative sorting in tinycbor.

Wrote a short proof of concept for this (removes old sorting behavior) cborvalidation.c:475:

        if (flags & CborValidateMapIsSorted) {
            if (previous) {
                uint64_t len1, len2;
                const uint8_t *ptr;

                /* extract the two lengths */
                ptr = previous;
                _cbor_value_extract_number(&ptr, it->parser->end, &len1);
                ptr = current;
                _cbor_value_extract_number(&ptr, it->parser->end, &len2);


                size_t bytelen1 = (size_t)(previous_end - previous);
                size_t bytelen2 = (size_t)(it->ptr - current);

                /*
                 * Offset of actual key value (not including type information) is bytelenX - lenX??
                 * What if key value is indefinite??
                 */

                int r = memcmp(&previous[bytelen1 - len1], &current[bytelen2 - len2], len1 <= len2 ? len1 : len2);

                if (r == 0 && len1 != len2)
                    r = len1 < len2 ? -1 : +1;
                if (r > 0)
                    return CborErrorMapNotSorted;
                if (r == 0 && (flags & CborValidateMapKeysAreUnique) == CborValidateMapKeysAreUnique)
                    return CborErrorMapKeysNotUnique;

            }

Would it be possible to add a flag that would allow for this kind of sorting?

Lingua principale
C
Stelle
634
Fork
222
Merge medio
1g 25m
PR unite (30g)
2

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di intel/tinycbor

Tutte le issue di intel/tinycbor

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.