James Hawkins truiken@gmail.com writes:
dlls/kernel32/profile.c | 2 +- dlls/kernel32/tests/profile.c | 30 ++++++------------------------ 2 files changed, 7 insertions(+), 25 deletions(-)
diff --git a/dlls/kernel32/profile.c b/dlls/kernel32/profile.c index 5d563a5..b6ad6d0 100644 --- a/dlls/kernel32/profile.c +++ b/dlls/kernel32/profile.c @@ -396,7 +396,7 @@ static PROFILESECTION *PROFILE_Load(HANDLE hFile, ENCODING * pEncoding) first_section->name[0] = 0; first_section->key = NULL; first_section->next = NULL;
- next_section = &first_section->next;
- next_section = &first_section;
This cannot be right. What happens to the original first_section then?
On Tue, Mar 24, 2009 at 3:42 AM, Alexandre Julliard julliard@winehq.org wrote:
James Hawkins truiken@gmail.com writes:
dlls/kernel32/profile.c | 2 +- dlls/kernel32/tests/profile.c | 30 ++++++------------------------ 2 files changed, 7 insertions(+), 25 deletions(-)
diff --git a/dlls/kernel32/profile.c b/dlls/kernel32/profile.c index 5d563a5..b6ad6d0 100644 --- a/dlls/kernel32/profile.c +++ b/dlls/kernel32/profile.c @@ -396,7 +396,7 @@ static PROFILESECTION *PROFILE_Load(HANDLE hFile, ENCODING * pEncoding) first_section->name[0] = 0; first_section->key = NULL; first_section->next = NULL;
- next_section = &first_section->next;
- next_section = &first_section;
This cannot be right. What happens to the original first_section then?
I don't really understand your question. By original first_section, do you mean the first_section that we loaded from an existing file or that is in the cache? If so, then the answer is that the cache is cleared when the file is re-read. That doesn't really seem like what you're asking though. next_section is just a poorly worded name for a list iterator which starts at the first section and loads all of the sections into the file. Without this fix, the first section is loaded as a blank section and the real first section starts second in the linked list. After all of the loading is done, the first_section is returned to the caller.
James Hawkins truiken@gmail.com writes:
This cannot be right. What happens to the original first_section then?
I don't really understand your question. By original first_section, do you mean the first_section that we loaded from an existing file or that is in the cache? If so, then the answer is that the cache is cleared when the file is re-read. That doesn't really seem like what you're asking though. next_section is just a poorly worded name for a list iterator which starts at the first section and loads all of the sections into the file. Without this fix, the first section is loaded as a blank section and the real first section starts second in the linked list. After all of the loading is done, the first_section is returned to the caller.
Yes, the first section is empty, it's supposed to hold keys that appear before the first section header (if any). With your patch it will simply be dropped (and leaked). A better patch would be to only create the first section as needed, when we encounter either a section header or a stand-alone key.
On Tue, Mar 24, 2009 at 3:50 PM, Alexandre Julliard julliard@winehq.org wrote:
James Hawkins truiken@gmail.com writes:
This cannot be right. What happens to the original first_section then?
I don't really understand your question. By original first_section, do you mean the first_section that we loaded from an existing file or that is in the cache? If so, then the answer is that the cache is cleared when the file is re-read. That doesn't really seem like what you're asking though. next_section is just a poorly worded name for a list iterator which starts at the first section and loads all of the sections into the file. Without this fix, the first section is loaded as a blank section and the real first section starts second in the linked list. After all of the loading is done, the first_section is returned to the caller.
Yes, the first section is empty, it's supposed to hold keys that appear before the first section header (if any). With your patch it will simply be dropped (and leaked). A better patch would be to only create the first section as needed, when we encounter either a section header or a stand-alone key.
Ah ok, I didn't know about that functionality. I will add more tests and a better fix.
-
Alexandre Julliard -
James Hawkins