gumbo: Make sure to use the char* pointer as the hashmap item

[flavorjones]

What problem is this PR intended to solve?

Previously we were passing a character string of variable length, but always copying 8 bytes into the item. It's not really a problem if the length of the string is less than 8, but it's more serious if the length is longer than 8.

Fixes #3500
Fixes #3508

Have you included adequate test coverage?

I've added test coverage that will fail under valgrind.

Does this change affect the behavior of either the C or the Java implementations?

The issue is only with the C (gumbo) implementation.

[stevecheckoway]

I only took a quick look (I'm on vacation without a computer) so I could be missing something. It looks like this is using the address of a local variable as the value in the hash set.

I'm assuming that the implementation is going to be storing a copy of that address (I'm basing that on the sizeof(char *) in the call to create the hash set; I haven't looked at the actual API) and using it in the lookup. If I'm correct about that, then I think this is undefined behavior.

I can take a closer look next week if that would be helpful.

Cheers from Athens!

[flavorjones]

@stevecheckoway Thanks, not urgent at all. I'd love your eyes but not worth interrupting vacation for.

The prescribed usage of the hashmap library is to use a fixed-length struct as the "item". I've cheated here a bit and am using the fixed-length pointer value as the "item". The char* points at the string allocated for the attribute name, and so I'm pretty sure it's OK to reference this string during tag tokenization.

The hashmap is thrown away in emit_current_tag, so the lifetime of the strings is longer than the lifetime of the hashmap. I think it's OK? But would appreciate your eyeballs when you're back.