On Tue, Jul 28, 2020 at 10:26 AM Peter Stephenson wrote: > > > On 28 July 2020 at 08:53 Daniel Shahaf wrote: > > > > It's clearly correct, but as written, the patch loses the distinction > > that these members are private to hashtable.c and should not be accessed > > by other parts of the code. Could you address that, please? If > > there's an easy way to have the compiler enforce this restriction, > > great; else, we can at least add a comment. > > One way is to have a "struct { ... } private" substructure, > which it makes it clear what's going on within the code (though comments > are obviously useful, too). How about this? The diff is a bit larger but the code is fairly straightforward. Only hashtable.c has access to internal fields, just like before the patch. In a nutshell, struct hashtable has only public data members. Within hashtable.c there is struct hashtableimpl, which has struct hashtable as the first data member. C allows casting a pointer to a struct to a pointer to its first data member and back without violating aliasing rules. Thus hashtable.c can cast struct hashtable* to struct hashtableimpl* in order to get access to internal fields. Roman.