On 16 March 2016 at 05:46, Sebastian Lackner sebastian@fds-team.de wrote:
To catch errors like http://source.winehq.org/patches/data/120308 easier in the future, I would like to propose, that we replace CONTAINING_RECORD and similar macros with a typesafe definition (on compilers where this is possible). The linux kernel source contains an example how to do that, but there are multiple solutions available:
#define container_of(ptr, type, member) ({ \ const typeof( ((type *)0)->member ) *__mptr = (ptr); \ (type *)( (char *)__mptr - offsetof(type,member) );})
One disadvantage is that we'll have to add explicit casts to a couple of places, like below. Other dlls which would require explicit casts at a couple of places:
amstream, d2d1, d3d11, d3d8, d3d9, ddraw, dwrite, msxml3, oleaut32, quartz, rpcrt4, vbscript
That implies you've tried the change. Did you find any issues other than the one in 120308? If not, I think this is rarely an issue in practice and not worth making legitimate cases uglier for.
On 16.03.2016 13:42, Henri Verbeet wrote:
On 16 March 2016 at 05:46, Sebastian Lackner sebastian@fds-team.de wrote:
To catch errors like http://source.winehq.org/patches/data/120308 easier in the future, I would like to propose, that we replace CONTAINING_RECORD and similar macros with a typesafe definition (on compilers where this is possible). The linux kernel source contains an example how to do that, but there are multiple solutions available:
#define container_of(ptr, type, member) ({ \ const typeof( ((type *)0)->member ) *__mptr = (ptr); \ (type *)( (char *)__mptr - offsetof(type,member) );})
One disadvantage is that we'll have to add explicit casts to a couple of places, like below. Other dlls which would require explicit casts at a couple of places:
amstream, d2d1, d3d11, d3d8, d3d9, ddraw, dwrite, msxml3, oleaut32, quartz, rpcrt4, vbscript
That implies you've tried the change. Did you find any issues other than the one in 120308? If not, I think this is rarely an issue in practice and not worth making legitimate cases uglier for.
There are a couple more places which technically use a wrong member field, and assume that the interface pointer is at the beginning of some structure. The generated code is fine though, and of course those issues could be fixed without pulling all changes into the Wine source. Nevertheless, the main reason for replacing CONTAINING_RECORD, LIST_ENTRY, ... would be to avoid new errors in the first place.
-
Henri Verbeet -
Sebastian Lackner