Front page | perl.perl5.porters |
Postings from October 2016
Re: hv.h hek definition
From: Aristotle Pagaltzis
October 2, 2016 00:57
Re: hv.h hek definition
Message ID: 20161002005711.GA96125@plasmasturm.org
* Todd Rinaldo <email@example.com> [2016-09-29 05:00]:
> IMO, the declaration for hek_key is VERY misleading.
Unfortunately it’s the C language misleading you, not the code. :-)
> In the context of a struct, what you end up with when you do char
> hek_key; is a char pointer followed by a char.
I’m afraid your mental model of arrays and pointers in C is seriously
broken. There is plenty of material on the distinction, so allow me to
just paste a link at you:
If that alone doesn’t help, googling [arrays vs pointers in c] should
provide plenty more. (That’s how I got that link: it was the first hit.
But I read it before pasting it.)
This is an aspect of C that took me a while to get a grip on, because
in trying to offer convenient semantics, the language ends up making the
difference elusively subtle to the unsuspecting.
> We exploit that to store the flags in the char slot and we inject
> a string pointer in hek_key.
There is no string pointer ever getting stored. hek_key is an array, not
> The comments are misleading and wrong AFAIK, the string does not have
> flags on the end of it. instead they're stored in the byte on the tail
> of the struct:
> #define HEK_FLAGS(hek) (*((unsigned char *)(HEK_KEY(hek))+HEK_LEN(hek)+1))
The byte on the tail of the struct is also the byte on the tail of the
hek_key array, because the hek_key array is part of the struct, so the
comments are correct.
> I can see no reason why this should be written this way. It is also
> difficult to populate this struct from C because the char* is mixed in
> with the char.
There is no char* whatsoever. Only a char.
> C doesn't like you altering the char pointer.
There is no char pointer, only a char array, and you can’t alter its
address, because an array is wherever it is and that’s where it is. The
pointer you get when you refer to the array is only a value, it is not
> Is there some obscure compiler subtlety that caused us to originally
> define it this way back in the old days?
It’s not a compiler obscurity but a fundamental aspect of C. Although
it is indeed subtle.
> Is there a reason it shouldn't be fixed?
Writing it the way you proposed would require two memory allocations
instead of just one, and require storage for an extra pointer.
Aristotle Pagaltzis // <http://plasmasturm.org/>