Raphael wrote:
Hi,
Changelog:
- begin of dwarf debug lines parsing
- better robustness
- support of unamed syms
- better traces
TODO:
- find a clean way to handle forward declarations
- debug lines parsing
Index: type.c
RCS file: /home/wine/wine/dlls/dbghelp/type.c,v retrieving revision 1.12 diff -u -r1.12 type.c --- type.c 18 Apr 2005 15:34:10 -0000 1.12 +++ type.c 10 Oct 2005 07:02:25 -0000 @@ -204,8 +204,8 @@
- the others (bit fields)
*/ BOOL symt_add_udt_element(struct module* module, struct symt_udt* udt_type,
const char* name, struct symt* elt_type,
unsigned offset, unsigned size)
const char* name, struct symt* elt_type,
unsigned offset, unsigned size)
{ struct symt_data* m; struct symt** p; @@ -220,7 +220,7 @@ assert(m); assert(m->symt.tag == SymTagData); if (m->hash_elt.name[0] == name[0] && strcmp(m->hash_elt.name, name) == 0)
return TRUE;
return FALSE;
}
if ((m = pool_alloc(&module->pool, sizeof(*m))) == NULL) return FALSE;
I don't see the reason of changin the returnd value from TRUE to FALSE
On Monday 10 October 2005 21:27, Eric Pouech wrote:
BOOL symt_add_udt_element(struct module* module, struct symt_udt*
assert(m->symt.tag == SymTagData);
if (m->hash_elt.name[0] == name[0] && strcmp(m->hash_elt.name,
name) == 0) - return TRUE;
return FALSE;
}
if ((m = pool_alloc(&module->pool, sizeof(*m))) == NULL) return
FALSE;
I don't see the reason of changin the returnd value from TRUE to FALSE
usefull because with that i have found a bug ;) (trying to redefine some elements too many times)
No problem as all the dbghelp code don't test return code :p
Regards, Raphael
Raphael wrote:
On Monday 10 October 2005 21:27, Eric Pouech wrote:
BOOL symt_add_udt_element(struct module* module, struct symt_udt*
assert(m->symt.tag == SymTagData);
if (m->hash_elt.name[0] == name[0] && strcmp(m->hash_elt.name,
name) == 0) - return TRUE;
return FALSE;
}
if ((m = pool_alloc(&module->pool, sizeof(*m))) == NULL) return
FALSE;
I don't see the reason of changin the returnd value from TRUE to FALSE
usefull because with that i have found a bug ;) (trying to redefine some elements too many times)
No problem as all the dbghelp code don't test return code :p
Regards, Raphael
but it's of no use with the patch you sent, so why clobber the patch with this ? A+
but it's of no use with the patch you sent, so why clobber the patch with this ?
no because i think its better to avoid assert in this case on dbghelp code :) But if you prefer i can restore original code
A+
Regards, Raphael
Raphael wrote:
but it's of no use with the patch you sent, so why clobber the patch with this ?
no because i think its better to avoid assert in this case on dbghelp code :) But if you prefer i can restore original code
IMO the correct fix would in field insertion to return one of three values: - success (didn't exist before) - did exist before - couldn't add (instead of the current success/failure mode) so that every debug info parser can pick what it wants my main objection here is that you're making modifications for something you don't use (in the patch you sent). For readability and acceptance of patches it's better to only include it if you make use of it.
A+