Just a reminder to everyone involved with profile.c:
I have watched the git log of the somewhat recent changes to kernel32/profile.c.
The profile API does not work that way.
The current situation is even worse than before, when the undocumented empty string section and empty keys were not implemented at all. The current situation leads to consistent INI file corruption when the applications use the undocumented empty string section and empty keys.
I tried to explain how the API works under Windows many times. This is another casual attempt at giving you a reality check. If you are interested, you can contact me for further details, or look at the testcases in my last patch (search for profile.c / Claudio Fontana).
A good fix in profile.c is difficult because of the unfortunate use of the empty string as sentinel in the implementation. Probably rewriting the module would be a better idea.
In short again: empty string section is just another (valid) section under Windows. Depending on the windows version the section is represented in the saved file after []\r\n at the beginning of the INI file or with no header at all.
The empty key can be requested and saved in a named section. The empty key in a named section is just another (valid) key under Windows. The empty key value is represented in the saved file after the header of the appropriate section in this way, just as logic would suggest:
[header] =value
Those "empty string" sections and "empty string" keys should be found when querying using the profile API. Currently it does not happen, leading to INI corruption (multiple repeated empty sections' values, none of which are found by the API).
Regards,
Claudio Fontana