Ok, with all the talk about AppVeyor/MSYS2 I decided to try to build libconfuse using the original MSYS (which I have installed, I don't have MSYS2) and MSVC 2010. I bumped into a number of difficulties, all of which I have solved in this branch. Except one, namely the C99 initializers from when the simple option union was introduced (57b9738acd5dd976bac95270885ec3532b18b553). I reverted that commit on top of this branch and I was able to build with my old tools like this:

Open a MSVC 2010 command shell, and launch MSYS from it. From within the MSYS shell, do .../configure --disable-examples CC=cl CFLAGS=-MD RANLIB=: NM="dumpbin -symbols" AR=lib make make check

Everything passes. I think the C99 initializers are supported by newer MSVC, so that particular problem will solve itself over time. Other than that, for projects that I maintain, I detest multiple build systems. Therefore, I very much favor supporting MSVC through autotools instead of project files that always ends up lagging behind.

However, that puts Windows user in a position where they have to install MSYS. But the patches in this branch doesn't look all that nasty, most of them just shows that building with older MSVC hasn't been done in a while. Has anybody built with newer MSVC recently? And these patches doesn't stop anyone from keeping maintaining the windows project files...

Anyway, it should be possible to add a build with MSYS/MSVC on AppVeyor. But someone has to verify that the work I put into automake/libtool to support MSYS/MSVC a couple of years ago works with MSYS2 as well, I can't really see why it would fail, but I wouldn't be surprised if there is some quirk to figure out...

Cheers, Peter

In upgrading to libconfuse 3.1, I am now receiving the following error on mingw builds for Windows:

libconfuse.a(libconfuse_la-fmemopen.o): In function `fmemopen':
fmemopen.c:110: undefined reference to `funopen'

This can be reproduced on Debian/Ubuntu by installing the mingw crosscompiler:

sudo apt install gcc-mingw-w64-x86-64
cd confuse
CC=x86_64-w64-mingw32-gcc ./configure --enable-shared=no --disable-examples
make

Then try linking libconfuse.a to a trivial app. Since I never build the libconfuse examples in my Windows builds, I hadn't realized that they didn't compile with mingw, but in theory, they could show the issue too. If nothing else, you can see the warning the funopen isn't defined when compiling fmemopen.c.

I'm not completely sure how best to work around this issue. In the past when I've run into uses of fmemopen, it has been pretty easy to remove them, but I don't think that's the case here. However, I also don't know how one would implement fmemopen without funopen. Hence I'm posting here to see if there are any other ideas.

We use libconfuse in tilda and often have the problem that we want to deprecate config options but this leads to problems:

When the config option is still present in the config file (e.g. for upgrading users) then libconfuse throws an error and we need to reset the config.

We are currently discussing if we replace libconfuse with another config library due to this, or if we are going to add a new feature to libconfuse. I would like to know if this project is still being actively maintained/developed and how likely it is that a patch will be accepted into libconfuse. If a patch would be accepted, then we might add a CFGF_DEPRECATED to the list of flags that causes libconfuse to ignore the config value and drop it when the config file is saved next. Possibly we could also split this into separate flags with a CFGF_DROP flag.

Please let us know what your plans with libconfuse are and if we can somehow help you.

No PR in sight, that can't be right :-)

From the commit message:

Consider that you have a command line parser, and have parsed a line into tokens. It turns out that the first token, the command, is a 'set-cfg-variable' type of command and that the other tokens describe the new value, and possibly what variable to set.

I.e. you are given a command "set foo-list bar gazonk zilch"

and as a response to this command you want to set the "foo-list" option to { "bar", "gazonk", "zilch" }. There is no current API to do this in a simple maner, if you want to cover up for the possibility of syntax errors during parsing and arbitrary number of command line arguments.

So, add cfg_setmulti (and cfg_opt_setmulti) to support this.

1. lexer.c not generated when compile use MSVC.
2. issue for coding. --------------------Configuration: libConfuse - Win32 Debug-------------------- Compiling... confuse.c e:\github\libconfuse\src\confuse.c(838) : error C2059: syntax error : '.' e:\github\libconfuse\src\confuse.c(1123) : error C2065: 'ssize_t' : undeclared identifier e:\github\libconfuse\src\confuse.c(1123) : error C2146: syntax error : missing ';' before identifier 'n' e:\github\libconfuse\src\confuse.c(1123) : error C2065: 'n' : undeclared identifier e:\github\libconfuse\src\confuse.c(1124) : error C2143: syntax error : missing ';' before 'type' e:\github\libconfuse\src\confuse.c(1126) : error C2065: 'path' : undeclared identifier e:\github\libconfuse\src\confuse.c(1128) : error C2143: syntax error : missing ';' before 'type' e:\github\libconfuse\src\confuse.c(1137) : error C2065: 'np' : undeclared identifier e:\github\libconfuse\src\confuse.c(1139) : warning C4047: 'return' : 'char *' differs in levels of indirection from 'int ' e:\github\libconfuse\src\confuse.c(1145) : error C2079: 'st' uses undefined struct 'stat' e:\github\libconfuse\src\confuse.c(1325) : warning C4090: 'function' : different 'const' qualifiers e:\github\libconfuse\src\confuse.c(1325) : warning C4022: 'free' : pointer mismatch for actual parameter 1 e:\github\libconfuse\src\confuse.c(1329) : warning C4090: 'function' : different 'const' qualifiers e:\github\libconfuse\src\confuse.c(1329) : warning C4022: 'free' : pointer mismatch for actual parameter 1 Error executing cl.exe.

libConfuse.dll - 9 error(s), 5 warning(s)

setlocale might interfere with what the app wants, and a followup setlocale call might destroy the returned string from a previous setlocale call (by the app).

I follow the instructions as per INSTALL document and do the following. I have Win 7 and git bash console.```

invoke the git bash console.

cd c:/python36/confuse-3.2 ./configure # goes through all the checking - takes about one minute creates various files. configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating examples/Makefile config.status: creating po/Makefile.in config.status: creating m4/Makefile config.status: creating tests/Makefile config.status: creating doc/Makefile config.status: creating doc/Doxyfile config.status: creating libconfuse.pc config.status: creating libconfuse.spec config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands config.status: executing libtool commands config.status: executing po-directories commands config.status: creating po/POTFILES config.status: creating po/Makefile sh: __git_ps1: command not found`

The last line sh: __git_ps1:command not found # I don't understand how this may assist me.

$ make C:/mingw64/bin/make all-recursive make[1]: Entering directory 'C:/python36/confuse-3.2' Making all in m4 make[2]: Entering directory 'C:/python36/confuse-3.2/m4' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory 'C:/python36/confuse-3.2/m4' Making all in po make[2]: Entering directory 'C:/python36/confuse-3.2/po' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory 'C:/python36/confuse-3.2/po' Making all in src make[2]: Entering directory 'C:/python36/confuse-3.2/src' C:/Program Files/Git/usr/bin/sh.exe ../libtool --tag=CC --mode=compile gcc -DLOCALEDIR="/usr/local/share/locale" -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -DBUILDING_DLL -g -O2 -MT libconfuse_la-confuse.lo -MD -MP -MF .deps/libconfuse_la-confuse.Tpo -c -o libconfuse_la-confuse.lo test -f 'confuse.c' || echo './'confuse.c /usr/bin/sh: C:/Program: No such file or directory make[2]: *** [makefile:479: libconfuse_la-confuse.lo] Error 127 make[2]: Leaving directory 'C:/python36/confuse-3.2/src' make[1]: *** [makefile:521: all-recursive] Error 1 make[1]: Leaving directory 'C:/python36/confuse-3.2' make: *** [makefile:407: all] Error 2 sh: __git_ps1: command not found

Why do I get all these errors, "no such file or directory" and sh:__git_ps1 command not found when I got the *.zip package confuse-3.2.zip without modifying it?

Thank you in advance, Anthony of Sydney

This pull request fixes all the tests that were failing because of differences between mingw-w64 (a GCC compiler for Windows) and Linux. When I combined this pull request with pull request #27, I got all the tests to pass in MSYS2.

0285479 introduced a new field comment in the middle of struct cfg_t which causes an ABI break.

See

• i3/i3status#224
• https://bugs.debian.org/872078

Seems #81 does not catch this.

This pull request reindents the code base to Linux coding style, as proposed in issue #33, skipping only the Windows specific code in windows/ and examples/wincfgtest.c.

Signed-off-by: Joachim Nilsson [email protected]

Hey, I've stumbled across a possible memory leak - not sure whether it's intentional or not -

It appears as if the free_cfg() library function neglects to free the yy_buffer_stack global variable.

I externed the cfg_yylex_destroy() function and used it straight after calling to free_cfg() and the memory leak was gone.

Pass the testsuite when build with sanitizers, e.g. CFLAGS=-O1 -g -fsanitize=address -fsanitize-address-use-after-scope -fsanitize-address-use-after-return=always -fno-omit-frame-pointer -fsanitize=undefined -fsanitize=nullability -fsanitize=implicit-conversion -fsanitize=integer -fsanitize=float-divide-by-zero -fsanitize=local-bounds:

• Avoid calling memcpy with NULL pointer and length 0 Found by running the test suite with undefined behavior sanitizer:

  confuse.c:674:18: runtime error: null pointer passed as argument 2, which is declared to never be null
  /usr/include/string.h:44:28: note: nonnull attribute specified here
      #0 0x55f77032e601 in cfg_dupopt_array ./libconfuse/src/confuse.c:674:2
      https://github.com/libconfuse/libconfuse/issues/1 0x55f770328227 in cfg_setopt ./libconfuse/src/confuse.c:1063:25
      https://github.com/libconfuse/libconfuse/pull/2 0x55f77032f537 in cfg_init_defaults ./libconfuse/src/confuse.c:861:4
      https://github.com/libconfuse/libconfuse/issues/3 0x55f770335dbb in cfg_init ./libconfuse/src/confuse.c:1877:2
      https://github.com/libconfuse/libconfuse/issues/4 0x55f770321ff7 in main ./libconfuse/tests/keyval.c:50:8
      https://github.com/libconfuse/libconfuse/issues/5 0x7f4bba429209 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
      https://github.com/libconfuse/libconfuse/pull/6 0x7f4bba4292bb in __libc_start_main csu/../csu/libc-start.c:389:3
      https://github.com/libconfuse/libconfuse/pull/7 0x55f7702623c0 in _start (./libconfuse/tests/keyval+0x3a3c0)
  

• Avoid implicit integer conversions

  confuse.c:601:30: runtime error: implicit conversion from type 'long' of value -1 (64-bit, signed) to type 'unsigned int' changed the value to 4294967295 (32-bit, unsigned)
      #0 0x55bb8fcd6f30 in cfg_getsec ./libconfuse/src/confuse.c:601:30
      https://github.com/libconfuse/libconfuse/issues/1 0x55bb8fcd23e4 in main ./libconfuse/tests/section_getopt.c:92:2
      https://github.com/libconfuse/libconfuse/pull/2 0x7f380da29209 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
      https://github.com/libconfuse/libconfuse/issues/3 0x7f380da292bb in __libc_start_main csu/../csu/libc-start.c:389:3
      https://github.com/libconfuse/libconfuse/issues/4 0x55bb8fc123b0 in _start (./libconfuse/tests/section_getopt+0x3b3b0)
  

• tests: check additional calls and results

• tests: skip test with broken fmemopen under sanitizers fmemopen(2) is broken with address and memory sanitizer, see https://github.com/google/sanitizers/issues/628.

Format attributes help compilers to warn on format string misuses, like:

cfg_error(cfg, user_defined_input)  // potential security issue
cfg_error(cfg, "foo %d", "bar")


confuse.c:1246:20: warning: format string is not a string literal [-Wformat-nonliteral]
                vfprintf(stderr, fmt, ap);
                                 ^~~

Guard the annotation with __GNUC__, defined by GCC and Clang, which support the GNU extension of function format attributes.

TODO: Untested on Windows.

Description

cfg_t *cfg_addtsec(cfg_t *cfg, const char *name, const char *title) can't return the pointer to the section if already exists.

Source Code Snippet

Definition

DLLIMPORT cfg_t *cfg_addtsec(cfg_t *cfg, const char *name, const char *title)
{
	cfg_opt_t *opt;
	cfg_value_t *val;

	if (cfg_gettsec(cfg, name, title))
		return NULL;

	opt = cfg_getopt(cfg, name);
	if (!opt) {
		cfg_error(cfg, _("no such option '%s'"), name);
		return NULL;
	}
	val = cfg_setopt(cfg, opt, title);
	if (!val)
		return NULL;

	val->section->path = cfg->path; /* Remember global search path. */
	val->section->line = 1;
	val->section->errfunc = cfg->errfunc;

	return val->section;
}

Declaration

Note: * @return A pointer to the created section or***if the section already exists a pointer to that section***is returned. If the section could not be created or found, 0 is returned.

/** Create a new titled config section.
 *
 * @param cfg The configuration file context.
 * @param name The name of the option.
 * @param title The title of this section.
 *
 * @return A pointer to the created section or if the section
 * already exists a pointer to that section is returned.
 * If the section could not be created or found, 0 is returned.
 */
DLLIMPORT cfg_t *cfg_addtsec(cfg_t *cfg, const char *name, const char *title);

Possible Resolution

 DLLIMPORT cfg_t *cfg_addtsec(cfg_t *cfg, const char *name, const char *title)
 {
+	cfg_t *sec;
 	cfg_opt_t *opt;
 	cfg_value_t *val;

+	sec = cfg_gettsec(cfg, name, title);
+	if (sec)
+		return sec;
-	if (cfg_gettsec(cfg, name, title))
-		return NULL;
 
 	opt = cfg_getopt(cfg, name);
 	if (!opt) {
 		cfg_error(cfg, _("no such option '%s'"), name);
 		return NULL;
 	}
 	val = cfg_setopt(cfg, opt, title);
 	if (!val)
 		return NULL;
 
 	val->section->path = cfg->path; /* Remember global search path. */
 	val->section->line = 1;
 	val->section->errfunc = cfg->errfunc;
 
 	return val->section;
 }

Hi! I wonder if there is any chance to make const-qualification of parameters in some exported functions?

For example, change cfg_getopt(cfg_t *cfg, const char *name); to cfg_getopt(const cfg_t *cfg, const char *name);.

This will allow to write more const (pure) functions, especially in C++ projects. However, it will be require to change the error reporting function prototype from: typedef void (*cfg_errfunc_t)(cfg_t *cfg, const char *fmt, va_list ap); to typedef void (*cfg_errfunc_t)(const cfg_t *cfg, const char *fmt, va_list ap);

While I see no reason to change cfg_t data inside the callback for custom error reporting, I suppose there might be use cases for this. The above changes may also break backward compatibility. But the tests of this project pass successfully after such changes on my local machine.

I think it would be great to have a general syntax highlighting direction. As a naive user I don't know what format to choose in VSCode. This could be solved by giving a general syntax highlighting direction in the README or create a plugin for mainstream IDEs. I assume that there is an existing format that is fundamentally compatible.