Re: [PATCH 2/2] Documentation Update.

[Qing Zhao <qing.zhao@oracle.com>]

> On Feb 2, 2023, at 11:25 PM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
> 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 <zackw@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.

Thanks a lot for the info.

Looks like it’s good time to start deprecating this misfeature from GCC.

Qing

> 
> Sid