Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Alternative map sorting

Abierto
#173 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
c
Área
embedded-iot

Línea de trabajo

Comienza en cborvalidation.c alrededor de la línea 475 y revisa los flags existentes de ordenación de mapas y unicidad. Aclara si la ordenación alternativa debe reemplazar o complementar el comportamiento actual y, después, define el orden esperado, el tratamiento de las claves y el comportamiento ante claves duplicadas; la finalización depende de acordar el diseño y el alcance de la implementación.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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?

Lenguaje dominante
C
Estrellas
634
Forks
222
Merge medio
1 d 25 min
PR fusionados (30 d)
2

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de intel/tinycbor

Todos los issues de intel/tinycbor

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.