Projects / libconfigduo / Comments

Comments for libconfigduo

29 Apr 2011 19:31 mesmerism

Yes, you need to escape all backslashes in strings as \\, just like you would in C/C++.

28 Apr 2011 11:30 dr_rumpel

Hi,

if a string is a regular expression itself, for example "/\.~lock\.", libconfig
will parse it so the result will be "/.~lock.".

If a string is "\", libconfig will report a syntax error.

03 Mar 2011 14:57 ice_cool

[PATCH] Typo in the help files ('cnost' instead of 'const').

There is a typo in doc/libconfig.info and doc/libconfig.texi :

--- a/doc/libconfig.info
+++ b/doc/libconfig.info
- -- Method on Config: cnost char * getIncludeDir ()
+ -- Method on Config: const char * getIncludeDir ()

--- a/doc/libconfig.texi
+++ b/doc/libconfig.texi
-@deftypemethodx Config {cnost char *} getIncludeDir ()
+@deftypemethodx Config {const char *} getIncludeDir ()

03 Mar 2011 14:46 ice_cool

[@include and environment variables]

Hi,
I have a patch which allow to insert variables in the pathes for @include directives.
I supports Unix variables ($VAR and ${VAR}) or WIN32 (%VAR%).
I could add an additionnal option to libconfig to enable/disable this feature, but at the moment, it is always ON.
Tell me if you are interested.

note : this patch has nothing to do with my other proposal about integer overflow.
--
Fred

01 Mar 2011 15:07 ice_cool

Hi,
we ran into a problem with liconfig, running on a 32bits platform, while we have always been usign 64bits platform.
Appart from usual silly problems with integer sizes, we add some surprise with libconfig, having enabled autoconvert.
When setting a TypeInt64 value into a TypeInt Setting, if value >= INT32_MAX or <= INT32_MIN, the setting is silently set to 'zero'.
The problem here is not the conversion itself, but the "silently".
Disabling autioconvert seems far too radical.

I suggest that a new option CONFIG_OPTION_OVERFLOW_ERROR is added.
With this option enabled, if libconfig detects some overflow (as it already checks), it reports a failure.
* C API : it implies to add some return value to config_setting_get_int. In order not to break the current API, I suggest to create config_setting_get_int_ex ('extended') or any other name, if you are more inspired than I am.
* C++ API : send a TypeException in 'Setting::operator=(const long long &value)'
I have a patch almost ready, if you are interested.

--
Fred

p.s. it seems that there are also some other places, where libconfig makes some implicit assumptions on how to handle type conversion. For instance, in 'Setting::operator unsigned long long() const throw(SettingTypeException)', the returned value may be silently saturated to zero, without any warning. Overflow detection It should be possible to trigger some failure report on this kind of situation.

03 Feb 2011 08:09 paul_hilton

Could TypeGroup be added to the data types for which assignement works?
Setting & operator = (Setting & value)
where value is a group, so that I can take group settings from one Config and add them to another, along with all their values (recursively)?

23 Dec 2010 04:51 mbaitoff

Did you ever thought about introducing schemas and writing a function to validate a config file against such a schema? I found it very difficult to re-write config file layout checkers every time I add minor change to config.
Or, it might be useful to implement a generator that would auto-produce a source files that will check the correctness (not syntax, but logical) of the config file.
The same approach was used with getopt() function - there is a 'gengetopt' tool that generates source files that check the logical correctness of the command-line options according to the tiny 'schema' describing the mandatory and optional parameters, their mutual compatibility etc.

25 Oct 2010 07:28 mesmerism

re: SettingCFG, SettingXML

I don't understand why this would require changes to libconfig itself; can't you simply implement this framework as a layer on top of libconfig?

25 Oct 2010 07:25 mesmerism

re: replace items in a list

I think the simplest solution for this would be to add a new function, e.g., for the C API: config_setting_retype_elem(config_setting_t *setting, int index, int type) that resets an existing element to a new type and sets its value to the default value for that type. Thus you could call this function to clear out the old value and change the type, and then call one of the existing functions to set the new value. If you can provide a patch that adds this to both the C and C++ APIs, I can include it in a future release.

12 Oct 2010 15:22 DennyB

Hi,

I have to do a porting of a project and I need to be compliant with the old xml config file which is a custom xml file.
The interface of your lib is interesting so I thought to modify the C++ part of the library and I made these changes:

- I create two abstract classes SettingBase and ConfigBase into libconfigBase.hpp
- I create two derived classes, SettingCFG and ConfigCFG, derived from those above into libconfigCFG.hpp

In this way I can write a SettingXML and ConfigXML classes which will have the same interface.
If it could be interesting, let me know.

Screenshot

Project Spotlight

ReciJournal

An open, cross-platform journaling program.

Screenshot

Project Spotlight

Veusz

A scientific plotting package.