SUBJECT: Inquiry regarding inconsistent sizing in `editorSyntax` struct

Open
#124 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
35/100
Issue type
Documentation
Clarity
Needs clarification
Activity status
Quiet
Tech stack
c
Domain
tooling

Research direction

Start by locating the editorSyntax struct definition and the later initialization of singleline_comment_start, multiline_comment_start, and multiline_comment_end. Compare how those fields are used, then clarify in the issue why their sizes differ; no specific file or test is named, so completion is a documented explanation rather than a code change.

Written by the indexing model from the issue text.

Description

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.

Dominant language
C
Stars
9.1k
Forks
1k
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from antirez/kilo

All issues in antirez/kilo

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.