SUBJECT: Inquiry regarding inconsistent sizing in `editorSyntax` struct
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 1/5
- Tiempo estimado
- Menos de una hora
- Aptitud para principiantes
- 35/100
Línea de trabajo
Empieza por localizar la definición de la estructura editorSyntax y la inicialización posterior de singleline_comment_start, multiline_comment_start y multiline_comment_end. Compara cómo se utilizan esos campos y, a continuación, aclara en el issue por qué sus tamaños difieren; como no se especifica ningún archivo ni prueba concretos, la finalización consiste en una explicación documentada y no en un cambio de código.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Hello,
I am relatively new to C programming so forgive me if I am mistaken. However, I noticed while looking at the struct, that there was a sizing inconsistency. Here is the definition of the struct:
struct editorSyntax {
char **filematch;
char **keywords;
char singleline_comment_start[2];
char multiline_comment_start[3];
char multiline_comment_end[3];
int flags;
};
I noticed that singleline_comment_start is initialised with 2 characters for '//' defined later on, which cuts the null terminator off, and not making it a C string. However, in the multiline comment ending and starting, it leaves space for the null terminator as it is 3 bytes, and the start and ending of the multiline comment is 2 bytes. So 2 bytes for the comment sign and 1 byte for the null terminator.
Was dropping the null terminator singleline_comment_start a trick to save memory (which is what I thought it was)? If so, why is the multiline comment also not stored like that?
Your help woudl be appreciated.
- Lenguaje dominante
- C
- Estrellas
- 9.2k
- Forks
- 1k
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de antirez/kilo
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 68/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 55/100
-
Multi-line comment highlighting breaks after row deletionPosiblemente ocupada @davidklassen la tomó hace 271 días. Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 48/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 38/100
Todos los issues de antirez/kilo
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
containers/bubblewrap#826 ·
Los mantenedores suelen responder en 1 día
-
[compiler-rt] Rtsan-aarch64-NoInstTest: error: no such file or directory: 'NOTFOUND' (libatomic)Abiertobuild-problem compiler-rt:rtsan platform:linux
Dificultad 2/5 1-3 horas Aptitud para principiantes 63/100
llvm/llvm-project#239039 ·
Los mantenedores suelen responder en 1 día
-
component:obi contribfest go test
Dificultad 2/5 Menos de una hora Aptitud para principiantes 83/100
open-telemetry/opentelemetry-ebpf-instrumentation#4143 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
checkpoint-restore/criu#3304 ·
Los mantenedores suelen responder en 1 día
-
Separate Installation Commands into Individual Code BlocksPosiblemente ocupada @andrySD la tomó hoy. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
colbymchenry/codegraph#3241 ·
Los mantenedores suelen responder en 1 día