editorconfig / editorconfig-core-c

EditorConfig core library written in C (for use by plugins supporting EditorConfig parsing)

This repository is placeholder used for issue tracking for format issues and other universal EditorConfig issues, as well as the wiki pages.

editorconfig-core-c's Issues

editorconfig-core doesn't like square brackets in the parent folder name

followup of editorconfig/editorconfig#310
easy to reproduce: put the parent folder name in square brackets and you'll break the lib.

for instance:
editorconfig.exe c:\1\1.cpp works
editorconfig.exe c:\[1]\1.cpp is silent
editorconfig.exe c:\1]\1.cpp works
editorconfig.exe c:\1[\1.cpp crashes

Brace pairing check in ec_glob.c incorrect?

I was just reading the code in ec_glob.c and noticed this loop doesn't seem to be doing what the variable name would suggest. Checking for equal numbers of opening and closing braces doesn't necessarily mean they're "paired". It's not immediately obvious if or how this effects the correctness of the code, but I just thought I'd point it out in case it's a bug.

Usage of atoi() invokes undefined behaviour on integer overflow

The library code has 3 uses of the atoi() function, which causes signed integer overflow (and thus undefined behaviour) when passed a string whose numeric value is outside of the range INT_MIN ... INT_MAX. Also known as CERT ERR34-C.

Treat "none" value for indent_style as disabling this check

Lisp code often indents better with the dynamic SLIME style than a fixed width indent. Could editorconfig-core-c help check Lisp code better by treating "none" values as disabling the indent_style check. Some other EditorConfig do this, with:

[{*.lisp,*.lsp,*.scm,*.el,*.rkt,*.abcl,*.ccl,*.clisp,*.ecl,*.sbcl,.eclrc,.sbclrc,*.m,*.mm}]
indent_size = none

No update binaries to v0.12.2

On sourceforge download page, no update to v0.12.2.

I found binaries, but they are v0.12.1. a below list need to update to latest editorconfig core

• Debian = v0.12.1
• Chocolatey = v0.12.1
• SourceForge = v0.12.1

I found no way to see package information uploaded at pacman.

Only homebrew updated.

Please update binaries.

Not passing -vsver to subsequent calls of build.ps1

Trying to build this from source on windows for the first time I hit an error that Visual Studio 15 2017 is not installed. Which is true because I only have Visual Studio 17 2022 installed.

I believe the following two lines are missing the argument -vsver $vsver.

editorconfig-core-c/build.ps1

Lines 51 to 52 in aa6b3ed

	.\build.ps1 -proj pcre2 -init:$init -install:$install -arch $arch -config $config -static $static
	.\build.ps1 -proj core -init:$init -install:$install -arch $arch -config $config -static $static

Clarify dependencies

Is PCRE2 a dependency just for compilation, or is it used at runtime as well? I find it helpful when projects clearly separate compile-time and runtime dependencies.

Also, I think it would help to mention which versions of things are needed. I only see mention of requiring CMake 2.8.12+ on the Releases page for EditorConfig C Core 0.12.3. This should probably be in the INSTALL documentation.

Also, which versions of PCRE2 and GCC (or other cc implementations) are needed?

Program cannot find dynamic library when installing with a non-default prefix

[vagrant@localhost editorconfig-core-c]$ cmake . -DCMAKE_INSTALL_PREFIX=~/apps
-- Configuring done
-- Generating done
-- Build files have been written to: /home/vagrant/src/3party/editorconfig-core-c
[vagrant@localhost editorconfig-core-c]$ cmake --build . --target install
[ 45%] Built target editorconfig_shared
[ 90%] Built target editorconfig_static
[100%] Built target editorconfig_bin
Install the project...
-- Install configuration: ""
-- Up-to-date: /home/vagrant/apps/lib64/libeditorconfig.so.0.12.2
-- Up-to-date: /home/vagrant/apps/lib64/libeditorconfig.so.0
-- Up-to-date: /home/vagrant/apps/lib64/libeditorconfig.so
-- Up-to-date: /home/vagrant/apps/lib64/libeditorconfig_static.a
-- Up-to-date: /home/vagrant/apps/bin/editorconfig-0.12.2
-- Up-to-date: /home/vagrant/apps/bin/editorconfig
-- Up-to-date: /home/vagrant/apps/include/editorconfig/editorconfig.h
-- Up-to-date: /home/vagrant/apps/include/editorconfig/editorconfig_handle.h
[vagrant@localhost editorconfig-core-c]$ /home/vagrant/apps/bin/editorconfig
editorconfig: error while loading shared libraries: libeditorconfig.so.0: cannot open shared object file: No such file or directory

Looks like editorconfig is built with the assumption that the required dynamic libraries will be on the system search path, which may not always be the case. Could you update the linker flags and have it look in a relative rpath, as shown here?

Missing MIT license text for CMake_Modules/FindPCRE2.cmake

The build-system file CMake_Modules/FindPCRE2.cmake is from LuaDist:

editorconfig-core-c/CMake_Modules/FindPCRE2.cmake

Lines 1 to 5 in c25cd84

	# Copyright (C) 2018 Sven Strickroth <email AT cs-ware DOT de>
	# Copyright (C) 2007-2009 LuaDist.
	# Created by Peter Kapec <[email protected]>
	# Redistribution and use of this file is allowed according to the terms of the MIT license.
	# For details see the COPYRIGHT file distributed with LuaDist.

Despite this attribution, the MIT license contains the clause

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

and thus the full license text should be available in this repository, either as a separate file or perhaps copied into the header comment of CMake_Modules/FindPCRE2.cmake. I believe the correct license text is https://github.com/LuaDist/luadist/raw/5852ddc94d943210d72c6d3a42ad9b6c728cb4ee/COPYRIGHT.

Header files define reserved identifiers

The header include guards all start with something like:

#ifndef __EC_GLOB_H__
#define __EC_GLOB_H__

...but ISO C99 states:

7.1.3 Reserved identifiers
...
All identifiers that begin with an underscore and either an uppercase letter or another
underscore are always reserved for any use.

Typo in editorconfig_handle.c

Use of 'minor' instead of 'patch' in:
if (patch >= 0)
((struct editorconfig_handle*)h)->ver.patch = minor;

We fix this in our gnome-builder copy:

https://git.gnome.org/browse/gnome-builder/commit/?id=20d6603f64d603d45736e287f556b54498781162

`editorconfig_parse()` leaks memory when no `.editorconfig` files are found or there are no values

To reproduce, open a file in a libeditorconfig client from a directory whose ancestry contains no .editorconfig files. A leaks report (output of leaks <pid> on macOS will show something like this:

[irrelevant portions of stack omitted for clarity]
2   com.barebones.bbedit                  0x101cf146f editorconfig_parse + 559  editorconfig.c:507
1   libsystem_malloc.dylib             0x7fff6855dcf5 malloc + 21
0   libsystem_malloc.dylib             0x7fff6855dd9e malloc_zone_malloc + 140 
====
    99 (4.19K) << TOTAL >>
      1 (96 bytes) ROOT LEAK: 0x60000677dc20 [96]  length: 92  "/Users/siegel/Library/Containers/com.barebones.bbedit/Data/Library/Logs/BBEdit/.edi..."
      1 (96 bytes) ROOT LEAK: 0x60000677dce0 [96]  length: 85  "/Users/siegel/Library/Containers/com.barebones.bbedit/Data/Library/Logs/.editorconf..."
      1 (96 bytes) ROOT LEAK: 0x6000067822e0 [96]  length: 80  "/Users/siegel/Library/Containers/com.barebones.bbedit/Data/Library/.editorconfig"
      1 (96 bytes) ROOT LEAK: 0x600006795bc0 [96]  length: 81  "/Users/siegel/svn/trunk/BBEdit/FrameworksAndLibraries/LSPKit/LSPKit/.editorconfig"
      1 (80 bytes) ROOT LEAK: 0x600002258910 [80]  length: 65  "/Users/siegel/svn/trunk/BBEdit/LanguageModules/Java/.editorconfig"
      1 (80 bytes) ROOT LEAK: 0x6000022cd540 [80]  length: 65  "/Users/siegel/svn/trunk/BBEdit/LanguageModules/Rust/.editorconfig"
      1 (80 bytes) ROOT LEAK: 0x600002327c50 [80]  length: 72  "/Users/siegel/Library/Containers/com.barebones.bbedit/Data/.editorconfig"
      1 (80 bytes) ROOT LEAK: 0x600002327ca0 [80]  length: 67  "/Users/siegel/Library/Containers/com.barebones.bbedit/.editorconfig"
      1 (80 bytes) ROOT LEAK: 0x60000232a990 [80]  length: 67  "/Users/siegel/svn/trunk/BBEdit/FrameworksAndLibraries/.editorconfig"
      1 (80 bytes) ROOT LEAK: 0x60000232ac10 [80]  length: 74  "/Users/siegel/svn/trunk/BBEdit/FrameworksAndLibraries/LSPKit/.editorconfig"
      1 (64 bytes) ROOT LEAK: 0x6000018cae00 [64]  length: 60  "/Users/siegel/svn/trunk/BBEdit/LanguageModules/.editorconfig"
      1 (64 bytes) ROOT LEAK: 0x6000019028c0 [64]  length: 51  "/Users/siegel/svn/trunk/BBEdit/Source/.editorconfig"
      1 (64 bytes) ROOT LEAK: 0x600001bfb300 [64]  length: 51  "/Users/siegel/svn/trunk/BBEdit/Source/.editorconfig"
      1 (64 bytes) ROOT LEAK: 0x600001c284c0 [64]  length: 47  has-length-byte:  "Users/siegel/svn/trunk/BBEdit/dox/.editorconfig"
      1 (64 bytes) ROOT LEAK: 0x600001c2ed00 [64]  length: 60  "/Users/siegel/svn/trunk/BBEdit/LanguageModules/.editorconfig"
      1 (64 bytes) ROOT LEAK: 0x600001c44640 [64]  length: 47  has-length-byte:  "Users/siegel/svn/trunk/BBEdit/dox/.editorconfig"
      1 (64 bytes) ROOT LEAK: 0x600001cea100 [64]  length: 51  "/Users/siegel/svn/trunk/BBEdit/Source/.editorconfig"
      1 (64 bytes) ROOT LEAK: 0x600001d6bb00 [64]  length: 51  "/Users/siegel/svn/trunk/BBEdit/Source/.editorconfig"
      1 (64 bytes) ROOT LEAK: 0x600001d71a00 [64]  length: 51  "/Users/siegel/svn/trunk/BBEdit/Source/.editorconfig"
      1 (64 bytes) ROOT LEAK: 0x600001d73b00 [64]  length: 51  "/Users/siegel/svn/trunk/BBEdit/Source/.editorconfig"
      1 (64 bytes) ROOT LEAK: 0x600001d98800 [64]  length: 52  "/Users/siegel/svn/branches/BBEdit/13.5/.editorconfig"
      1 (48 bytes) ROOT LEAK: 0x6000010ecfc0 [48]  length: 44  "/Users/siegel/svn/trunk/BBEdit/.editorconfig"
      1 (48 bytes) ROOT LEAK: 0x6000010ed050 [48]  length: 37  "/Users/siegel/svn/trunk/.editorconfig"
      1 (48 bytes) ROOT LEAK: 0x6000010ee5b0 [48]  length: 46  "/Users/siegel/Library/Containers/.editorconfig"
      1 (48 bytes) ROOT LEAK: 0x6000010ee700 [48]  length: 35  "/Users/siegel/Library/.editorconfig"
      1 (48 bytes) ROOT LEAK: 0x6000010fc780 [48]  length: 44  "/Users/siegel/svn/trunk/BBEdit/.editorconfig"
      1 (48 bytes) ROOT LEAK: 0x600001111cb0 [48]  length: 37  "/Users/siegel/svn/trunk/.editorconfig"
      1 (48 bytes) ROOT LEAK: 0x60000113bf90 [48]  length: 37  "/Users/siegel/svn/trunk/.editorconfig"
      1 (48 bytes) ROOT LEAK: 0x60000113bfc0 [48]  length: 44  "/Users/siegel/svn/trunk/BBEdit/.editorconfig"
      1 (48 bytes) ROOT LEAK: 0x60000113de30 [48]  length: 44  "/Users/siegel/svn/trunk/BBEdit/.editorconfig"
      1 (48 bytes) ROOT LEAK: 0x6000011579f0 [48]  length: 37  "/Users/siegel/svn/trunk/.editorconfig"
      1 (48 bytes) ROOT LEAK: 0x600001157ae0 [48]  length: 44  "/Users/siegel/svn/trunk/BBEdit/.editorconfig"
[many more omitted for clarity]

The origin of the leak is the "no values" case:

    if (eh->name_value_count == 0) {  /* no value is set, just return 0. */
        free(hfp.full_filename);
        free(config_files);
        return 0;

The free(config_files) frees only the array block itself, and not the strings inside of it. This antipattern also occurs in the error case for reallocing the value array:

    if (eh->name_values == NULL) {
        free(hfp.full_filename);
        free(config_files);
        return EDITORCONFIG_PARSE_MEMORY_ERROR;
    }

I refactored the code at the cleanup: label into a separate function, and called that to ensure that the string array is properly freed. Patch follows:

diff --git a/src/lib/editorconfig.c b/src/lib/editorconfig.c
index e5262ca..6af834a 100644
--- a/src/lib/editorconfig.c
+++ b/src/lib/editorconfig.c
@@ -383,6 +383,20 @@ failure_cleanup:
     return NULL;
 }
 
+/*
+ * Free the memory used by an array of strings that was created by
+ * get_filenames().
+ */
+static void free_filenames(char **filenames)
+{
+    if (filenames != NULL) {
+        for (char** filename = filenames; *filename != NULL; filename++) {
+            free(*filename);
+        }
+        free(filenames);
+    }
+}
+
 /*
  * version number comparison
  */
@@ -564,7 +578,7 @@ int editorconfig_parse(const char* full_filename, editorconfig_handle h)
 
     if (eh->name_value_count == 0) {  /* no value is set, just return 0. */
         free(hfp.full_filename);
-        free(config_files);
+        free_filenames(config_files);
         return 0;
     }
     eh->name_values = hfp.array_name_value.name_values;
@@ -573,17 +587,12 @@ int editorconfig_parse(const char* full_filename, editorconfig_handle h)
             sizeof(editorconfig_name_value) * eh->name_value_count);
     if (eh->name_values == NULL) {
         free(hfp.full_filename);
+        free_filenames(config_files);
         return EDITORCONFIG_PARSE_MEMORY_ERROR;
     }
 
  cleanup:
-
-    if (config_files != NULL) {
-        for (config_file = config_files; *config_file != NULL; config_file++) {
-            free(*config_file);
-        }
-        free(config_files);
-    }
+    free_filenames(config_files);
     free(hfp.full_filename);
     free(hfp.editorconfig_file_dir);

0.12.5: BUILD_STATICALLY_LINKED_EXE=OFF and static library is build and installed

Looksl like despite passing to cmake BUILD_STATICALLY_LINKED_EXE=OFF libeditorconfig_static.a is build and installed.

Unexpected behavior on trailing slash

My intuition is that paths with trailing slashes should be treated the same as paths without them. I've written my EditorConfig core in Rust (which, at the time of writing, passes the full core test suite) to have this behavior.

This does not match EditorConfig Core C's behavior.

$ cat .editorconfig
root = true

[foo]
matched=true
$ editorconfig --version
EditorConfig C Core Version 0.12.5
$ editorconfig $PWD/foo
matched=true
$ editorconfig $PWD/foo/
$ ec4rs-parse $PWD/foo
matched=true
$ ec4rs-parse $PWD/foo/
matched=true

utf_8_char test is failing on Windows

See the output of the test on AppVeyor CI https://ci.appveyor.com/project/xuhdev/editorconfig-core-c/build/1.0.3#L2750 :

90/187 Testing: utf_8_char
90/187 Test: utf_8_char
Command: "C:/projects/bin/x64-static/core/bin/Release/editorconfig.exe" "-f" "utf8char.in" "C:/projects/editorconfig-core-c/tests/glob/中文.txt"
Directory: C:/projects/bin/x64-static/core/tests/glob
"utf_8_char" start time: Nov 27 10:32 Pacific Standard Time
Output:
----------------------------------------------------------
<end of output>

Separate config files for user/environment specific settings

Has there been any exploration into allowing multiple files based on naming convention that would allow users to override settings for their specific environment and can be ignored by VCS so the settings are not sent to other users on the project.

Ex.
.editorconfig - defaults
local.editorconfig or .editorconfig.local for user specific

Segfault while reading .editorconfig generated by JetBrains IDE

I've got segfault of Kate each time i'm trying to open any file in directory with .editorconfig, generated by JetBrains IDE

vovochka in ~/tmp $ ls -a  
.  ..  .editorconfig  test.php
vovochka in ~/tmp $ editorconfig /home/vovochka/tmp/test.php 
*** buffer overflow detected ***: editorconfig terminated
[1]    77219 abort (core dumped)  editorconfig /home/vovochka/tmp/test.php

.editorconfig:
editorconfig.txt

Got this trace:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007f3113b36b01 in __GI_abort () at abort.c:79
#2  0x00007f3113b78957 in __libc_message (action=<optimized out>, fmt=fmt@entry=0x7f3113c800f3 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007f3113c0954e in __GI___fortify_fail_abort (need_backtrace=need_backtrace@entry=true, msg=msg@entry=0x7f3113c8007a "buffer overflow detected") at fortify_fail.c:33
#4  0x00007f3113c09581 in __GI___fortify_fail (msg=msg@entry=0x7f3113c8007a "buffer overflow detected") at fortify_fail.c:44
#5  0x00007f3113c07430 in __GI___chk_fail () at chk_fail.c:28
#6  0x00007f3113c066c2 in __strcpy_chk (dest=dest@entry=0x7ffda5967b90 "ij_php_api_weight", src=0x7ffda5968cf0 "ij_php_array_initializer_new_line_after_left_brace", destlen=destlen@entry=50) at strcpy_chk.c:30
#7  0x00007f3113eb9352 in strcpy (__src=<optimized out>, __dest=0x7ffda5967b90 "ij_php_api_weight") at /usr/include/bits/string_fortified.h:90
#8  array_editorconfig_name_value_add (aenv=aenv@entry=0x7ffda596a140, name=name@entry=0x7ffda5968cf0 "ij_php_array_initializer_new_line_after_left_brace", value=value@entry=0x7ffda5968d25 "true")
    at /usr/src/debug/editorconfig-core-c-0.12.3-lp152.1.5.x86_64/src/lib/editorconfig.c:156
#9  0x00007f3113eb96d3 in ini_handler (hfp=hfp@entry=0x7ffda596a130, section=section@entry=0x7ffda5967ce0 "{*.ctp,*.phtml,*.module,*.php,*.php5,*.php4,*.hphp,*.inc}", 
    name=name@entry=0x7ffda5968cf0 "ij_php_array_initializer_new_line_after_left_brace", value=value@entry=0x7ffda5968d25 "true") at /usr/src/debug/editorconfig-core-c-0.12.3-lp152.1.5.x86_64/src/lib/editorconfig.c:269
#10 0x00007f3113eba1a6 in ini_parse_file (file=file@entry=0x5594ed38c410, handler=handler@entry=0x7f3113eb9510 <ini_handler>, user=user@entry=0x7ffda596a130) at /usr/src/debug/editorconfig-core-c-0.12.3-lp152.1.5.x86_64/src/lib/ini.c:180
#11 0x00007f3113eba34c in ini_parse (filename=filename@entry=0x5594ed38c350 "/home/vovochka/tmp/.editorconfig", handler=handler@entry=0x7f3113eb9510 <ini_handler>, user=user@entry=0x7ffda596a130)
    at /usr/src/debug/editorconfig-core-c-0.12.3-lp152.1.5.x86_64/src/lib/ini.c:205
#12 0x00007f3113eb9ad5 in editorconfig_parse (full_filename=<optimized out>, h=0x5594ed38c2b0) at /usr/src/debug/editorconfig-core-c-0.12.3-lp152.1.5.x86_64/src/lib/editorconfig.c:470
#13 0x00005594eb29e4e8 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/editorconfig-core-c-0.12.3-lp152.1.5.x86_64/src/bin/main.c:219

Option to use POSIX regex instead of PCRE

Currently src/lib/ec_glob.c depends on PCRE, which I guess is for cross-platform compat purposes. However, it's quite a large dependency for something that can also be done using regex.h on Linux/OS X/*BSD. Would you be open to a pull request that adds a build-time option to use the POSIX regex API instead of PCRE?

flatpak-builder: 'submodule' is not a git command

currently building flatpaked programs that have editorconfig as a dependency is not possible from a fresh git clone

output:

========================================================================
Building module libeditorconfig in /home/user/.var/app/org.gnome.Builder/cache/gnome-builder/flatpak-builder/build/libeditorconfig-13
========================================================================
Note: switching to 'v0.12.5'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at f6b0ca3 Release 0.12.5
git: 'submodule' is not a git command. See 'git --help'.
Error: module libeditorconfig: Дочірній процес закінчився з кодом 1

Be careful with indent_char for multiline strings

indent_char has some false positives for multiline strings, when the multiline string content happens to misalign with the overall file indentation settings. For example, this can happen with (ba)sh scripts.

Document building of library in CMake release mode

If the additional flag -DCMAKE_BUILD_TYPE=Release is passed to CMake when building, it will build in release mode. This gives you a build that:

• Runs the compiler at full optimisation level (-O3 on gcc)
• Does not include debugging symbols or assertions (-DNDEBUG)

If you think this'd be valuable to end users building from source, it may be worth including in your docs.

Make the command line document more UNIX-like

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798957#15

Unchecked malloc return value

There are 3 malloc() calls in the code with no NULL checks:

• src/lib/editorconfig.c:334
• src/lib/editorconfig.c:341
• src/bin/main.c:144

There are also about a dozen calls to strdup() and strndup() with the same problem.

Meson build support

Meson is an alternative build system and I wanted to know if you would accept a PR that adds support for it. The main reason this is wanted is because it supports 'subprojects' so other projects can easily bundle this library.

Add pkgconfig file

Installing a pkgconfig file will allow software to easily pick up system installed versions of the library.

Windows x64 build

Hi,

I'm trying to build editorconfig/editorconfig-notepad-plus-plus#9 for x64.
Which build options should i set to build pcre?

Regards
Michael

Bug: Star is not treated as a literal character inside brackets

The reference implementation does not treat a '*' character as a literal character inside brackets.

Current behavior

pattern = "ab[e*]cd.i";
  
// matches:
"ab[e]cd.i"
"ab[[]cd.i"
"ab[^]cd.i"
"ab[/]cd.i"
"ab[[]cd.i"
"ab[e[^/e[e]cd.i"

// does not match:
"abecd.i"
"ab*cd.i"

Expected behavior

the opposite

Allow relative file paths

If the a file path is not absolute, assume it is relative to the current working directory, as most command line tools operate.

Fix a leak of UT_array (var nums) in ec_glob.c

We fix it our gnome-builder copy:

https://git.gnome.org/browse/gnome-builder/commit/?id=12c0f65

Allow "none" value for charset

As a developer working with text files, I want most of my source code files ([*]) to use Unicode encoding, specifically UTF-8 charset. However, I want to be able to disable charset rules for certain folders, such as my examples/ directory, where I deliberately keep some non-UTF-8 and non-Unicode text files in order to test my applications. So it would be helpful if EditorConfig officially allowed more rules to be configured for most files, while allowing specific patterns (e.g., [*.html]) to disable the rule, such as with charset = none.

I see, eclint used the value unset by mistake. As there is no single, well-defined standard for CLI application to lint EditorConfig projects, some of the particular EditorConfig linters out there have varying degrees of support for the EditorConfig specification.

Glob: Handling of `?`

The glob wildcard ? is translated to a . in a regular expression.

With this, the glob expression a?b.c matches a_b.c but also a/b.c.

I think ? should be translated to [^/].

Please keep CHANGELOG up-to-date for easier downstream parsing

Current CHANGELOG shows v0.12.4 as latest

Chocolatey package is out of date

The INSTALL.md suggests you can install on Windows using Chocolatey, which is great. However, the package is out of date. It would be great if the latest package were made available on Chocolatey as well.

.editorconfig files with syntax errors can cause property lookup to fail, even if the file is in a directory beneath the "root" config

The current logic in the ini_handler() function seems to be to check every directory beneath the target directory for an .editorconfig file, from /.editorconfig upwards. If it encounters a config with root=true it clears the previous values and continues the traversal. If it encounters a file with INI syntax errors, it stops traversing at that directory and returns an error code.

This logic allows an .editorconfig file that shouldn't have any effect at all on the return value (because it's in a directory beneath the root config) to effectively prevent all property lookups in every directory above it.

I realize this is a weird edge case and fairly unlikely to happen, but I think it's worth mentioning anyway.

Path to using a system copy of inih?

Under Fedora Linux’s guidelines for bundled libraries, we’re required to contact upstreams publicly about a path to supporting external or system copies of any bundled librares.

I expect that this will not be possible with inih because, if nothing else, there are hard-coded size limits that differ between the upstream implementation and the forked version in editorconfig-core-c. However, a quick opinion on this would still be appreciated.

Support PCRE2

EditorConfig still uses PCRE and it should also support PCRE2.

PCRE2 was first released in 2015 and is the followup for PCRE (https://www.pcre.org/).

Path splitting algorithm isn't UNC-aware

According to @lowjoel in editorconfig/editorconfig-notepad-plus-plus#39 (comment) the path splitting algorithm at https://github.com/editorconfig/editorconfig-core-c/blob/082268b/src/lib/editorconfig.c#L519 isn't UNC-aware.

Bug: 0 is not considered a valid number for {num1..num2}

editorconfig-core-c/src/lib/ec_glob.c

Lines 377 to 379 in c32b33d

	/* we don't consider 0digits such as 010 as matched */
	if (*substring_start == '0')
	break;

This does not only discard numbers like "010", but also the "0" itself.

That means, the following pattern

*.orig.{0..9}

does not match the file

data.txt.orig.0

Update manpage text in editorconfig.h to point users to editorconfig.org [edited]

I just tried reading the documentation in man editorconfig, as installed by an Arch Linux package. It doesn't actually explain what the editorconfig program does, what a FILEPATH is or what the expected output is.

I am aware of what the EditorConfig project does in general and I already have a valid .editorconfig file, but how to use /usr/bin/editorconfig remains a mystery after reading this man page.

Shared Library Doesn't Exit Properly

In the terms of Fedora's RPM Packaging checker:

This library package calls exit() or _exit(), probably in a non-fork()
context. Doing so from a library is strongly discouraged - when a library
function calls exit(), it prevents the calling program from handling the
error, reporting it to the user, closing files properly, and cleaning up any
state that the program has. It is preferred for the library to return an
actual error code and let the calling program decide how to handle the
situation.