On 2023-02-02 03:33, Richard Biener wrote:
looking at PR77650 what seems missing there is the semantics of this
extension as expected/required by the glibc use. comment#5 seems
to suggest that for my example above its expected that
Y.x.data[0] aliases Y.end?! There must be a better way to write
the glibc code and IMHO it would be best to deprecate this extension.
Definitely the middle-end wouldn't consider this aliasing for
my example - maybe it "works" when wrapped inside a union but
then for sure only when the union is visible in all accesses ...
typedef union
{
struct __gconv_info __cd;
struct
{
struct __gconv_info __cd;
struct __gconv_step_data __data;
} __combined;
} _G_iconv_t;
could be written as
typedef union
{
struct __gconv_info __cd;
char __dummy[sizeof(struct __gconv_info) + sizeof(struct
__gconv_step_data)];
} _G_iconv_t;
in case the intent is to provide a complete type with space for
a single __gconv_step_data.
I dug into this on the glibc end and it looks like this commit:
commit 63fb8f9aa9d19f85599afe4b849b567aefd70a36
Author: Zack Weinberg <za...@panix.com>
Date: Mon Feb 5 14:13:41 2018 -0500
Post-cleanup 2: minimize _G_config.h.
ripped all of that gunk out. AFAICT there's no use of struct
__gconv_info anywhere else in the code.
I reckon it is safe to say now that glibc no longer needs this misfeature.
Sid
