This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linked List Implementation

On 11/27/2017 05:38 PM, Toebs Douglass wrote:
On 27/11/17 16:22, Florian Weimer wrote:
On 11/27/2017 01:19 PM, Toebs Douglass wrote:
I'd love to find some new ideas, things I've totally missed, use cases I had no idea about.

There's some disagreement whether inline allocation of keys/values needs to be supported,

Inline?  do you mean by this inside the data structure function calls?

Without pointer indirection.

whether key/value pointers should be void *,

What are the alternatives?

Concrete pointers and more macros to generate the struct definitions (or type-safe accessor functions).

others prefer function pointers (sometimes with a closure argument, sometimes without).

Do you mean function pointers for the API functions?  stored in say the state structure?

Yes. It provides for more code sharing, fewer macros, and thus better debugging, but reduces type safety and may counteract security hardening efforts.

Some are strictly opposed to aliasing violations which happen to work today, others want strict language conformance.

I'm not sure I've ever run into aliasing issues... why would you benefit from doing so / what would you be doing for it to occur anyway?

Lying about concrete types often enables additional code sharing, which reduces icache pressure and thus increases performance.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]