>> I guess there as many map implementations as there are C developers :-)
> Though I should say that yours from C99Containers look nice to use,
> despite the macros-as-template hell in the implementation :-)
Thanks! Well after some time, it became second nature to program like that :) But seriously, it is the only way to create fast generic code in C, and as a bonus you don't get type unsafety and casting-hell all over the place. It *can* create some code bloat (as with templates), but normally not a problem. Yes there are hundreds of C map implementations out there, but they are mostly pretty bad, trust me ;) (slow, bloated, buggy, bad API, incomplete, I could go on..)
> (what's the spirit? I don't know, you'll eventually get a feeling for it.)
Shouldn't be a huge problem, I'm quite old-school in this regard, and probably use way too much time optimizing for short and efficient code...
> But do try, if the implementation turns out to not add memory overhead and
> many source lines, and is generally in the spirit of TCC, why not :)
After looking more at the code, I could agree that a new map implementation may not be necessary. Normally local scopes have a fairly limited number of identifiers, it's the global scope that requires an efficient symbol table. I do understand how the table_ident is segmented into different types of lookups, but I would still need to look more into it to fully understand it.. E.g. It looks like the hashing table is primarily used for the preprocessor symbols, but partly also for other identifiers?
> Mostly because of the T in tiny c compiler and because no profiling shows field lookup to be a problem :)
I have to disagree with this assessment. I only found this bug after debugging myself. When structs have more than e.g. 10 fields, it is easy to add a name that already existed... But my main question is why are enums fields then checked, and what is the principal difference of checking enum fields and struct fields (other than struct creates a new scope during parsing)?