Groups are started by a header line containing the group name enclosed in ‘[‘ and ‘]’, and ended implicitly by the start of the next group or the end of the file. Each key-value pair must be contained in a group.
Key files are not INI files:
This syntax is obviously inspired by the .ini files commonly met on Windows, but there are some important differences:
.ini files use the ‘;’ character to begin comments, key files use the ‘#’ character.
Key files do not allow for ungrouped keys meaning only comments can precede the first group.
Key files are always encoded in UTF-8.
Key and Group names are case-sensitive. For example, a group called [GROUP] is a different from [group].
.ini files don’t have a strongly typed boolean entry type, they only have GetProfileInt(). In key files, only true and false (in lower case) are allowed.
that’s why i create this thread here and suggest something like
g_key_file_new_internel(GKeyFileType_INI)
g_key_file_new_internel(GKeyFileType_KeyWithoutGroup)
…
And the original g_key_file_new may call this g_file_new_internel
It won’t be exactly like this, i am just demostrating my idea.
Although i had not read any of the gkeyfile source code yet, i don’t think it will take too much trouble to change.
The simplest way may be create a dumb group name, which can be a non-conflicting GUID constant, when group name passed in is NULL. I mean, provide this frequently used logic inside API instead of asking users to implement outside as suggested in the gentoo forum thread. I guess this may cause the least effort of testing since no actual internel logic change.
Most programmer knows what a key value pair means, and not many know the exact specification you quoted.
programmer switch from HTML to Markdown because you have to provide <head>...<body> even you just want to write a simple sentence
In gentoo, locate *.conf return me a lot of .conf file without a groupname.
Of cause, i can choose other specialize library for key value pair file storage, but gkeyfile related functions will still be compiled into the lib binary even if i don’t reference them with #include, is that true?
Sorry, no. GKeyFile is not a general purpose “anything that looks a bit like INI files” parser. If you want to parse a format which doesn’t follow the key file specification, find or write a different parser.
Implementing, testing and maintaining the many small differences in the parser would cause too much confusion and potential for bugs in a fairly critical piece of code which a lot of people rely on. We have no interest in doing that.