libuv: The way libuv does inheritance violates strict aliasing

With strict aliasing (since C99, AFAIK) and something like:

struct base{
    BASE_FIELDS
};
struct derived{
    BASE_FIELDS
    DERIVED_FIELDS
};

reading struct derived through struct base* results in undefined behavior. The whole inheritance emulation libuv uses is broken with strict aliasing on.

Making those bases into named members would fix the problem.

I tentatively fixed it for Linux here https://github.com/pskocik/libuv/tree/inh . An unfortunate consequence is that it changes the API by changing how the variables are accessed.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 16 (13 by maintainers)

Commits related to this issue

Most upvoted comments

An unfortunate consequence is that it changes the API by changing how the variables are accessed.

That might make it acceptable for v2.x but we couldn’t land it in v1.x.

I had a discussion with a clang maintainer a few years ago about if what libuv does constitutes a strict aliasing violation. IIRC, our conclusion was that it depends on whether you interpret the language in the standard as nominal or structural. In the nominal interpretation it’s a violation, in the structural interpretation it’s not.

The standard doesn’t really say which one is correct but compilers all seem to take the structural approach.

EDIT: s/nominative/nominal/. Was studying Greek declensions earlier today, mind hadn’t really switched back to computers yet.

+1
bnoordhuis on Feb 20, 2017
Read more comments on GitHub
← libuv: Test failures on OpenBSD
libuv: uv_get_constrained_memory does not seem to work? (checked under cgroup2) →