This is the mail archive of the libc-alpha@sourceware.org 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: ToT glibc build problem with ToT GCC


On 8/29/19 11:28 AM, Martin Sebor wrote:
> On 8/29/19 10:26 AM, Steve Ellcey wrote:
>> I am building the latest glibc with the latest GCC and getting an error.
>> I see where, in locale/programs/charmap.h we declare bytes as a zero
>> length array in charseq but I am not sure where the write in
>> locale/programs/ld-ctype.c is.  The only line references that GCC seems
>> to be outputing refer to the declaration, not the use.
>>
>> Is anyone else seeing this?  Any ideas on what we should be changed?
>> The declaration?  The use?  Or is this a bogus warning from GCC that
>> we want to ignore?  I think that GCC is reporting this now due to Martin
>> Sebor's GCC patch for PR 83431 but I haven't verified that.
> 
> Yes, that's the most likely change.  It's unfortunate that GCC
> doesn't show the exact location of the assignment but the warning
> could be caused by the following in ctype_finish in ld-ctype.c:
> 
>     static struct charseq replace[2];
> 
>     if (!warned)
>       {
>         record_error (0, 0, _("\
> not all characters used in `outdigit' are available in the charmap"));
>         warned = 1;
>       }
> 
>     replace[0].nbytes = 1;
>     replace[0].bytes[0] = '?';
>     replace[0].bytes[1] = '\0';
>     ctype->mboutdigits[cnt] = &replace[0];
>       }
> 
> struct charseq is defined like so in charmap.h:
> 
>   struct charseq
>   {
>     const char *name;
>     uint32_t ucs4;
>     int nbytes;
>     unsigned char bytes[0];
>   };
> 
> Like Jeff said, the code certainly looks fishy.  AFAICS,
> the assignment "replace[0].bytes[0] = '?'" overwrites the first
> byte of replace[1].name and the warning is correct in pointing
> it out.
So apparently this is intentional (ick).  Essentially the second entry
in the replace array is really just meant to be space for the variable
part of the first entry.


Carlos has asked me to ask you to file a bug in glibc's bugzilla to get
this fixed and that we not try to have GCC cater to this use (amen!).

Jeff


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