On Sat, Oct 31, 2020 at 6:35 PM Jan Hubicka <hubi...@ucw.cz> wrote: > > On 10/29/20 1:40 PM, Richard Biener wrote: > > > On Thu, 29 Oct 2020, Jakub Jelinek wrote: > > > > > > > On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote: > > > > > > > > > > > > That's ugly and will for sure defeat warning / access code > > > > > > when we access this as char[], no? I mean, we could > > > > > > as well use 'int str[1];' here? > > > > > > > > > > Well, we always get char pointer via macro that is IMO OK, but I > am also > > > > > not very much in love with this. > > > > > > > > Do we treat signed char [...]; as typeless storage too, or just > > > > what the C++ standard requires (i.e. char, unsigned char and > std::byte > > > > where the last one is enum type with unsigned char underlying type)? > > > > > > All that is covered by is_byte_access_type which includes all > > > character types (including char16_t and wchar it seems) and std::byte. > > > > Well, that's a bug, apparently from the PR94923 patch (r11-499); > previously > > it was char, signed char, and unsigned char. And even that is too much; > > even C++98 said just char and unsigned char could be used for bytewise > > access. > > > > When C++17 clarified this with the notion of "provides storage", it > applied > > to only unsigned char and std::byte, not even the full set of byte-access > > types. We still need to allow bytewise access using plain char, but > perhaps > > we don't need to treat plain char arrays as typeless. > > > > Attributes to say that a particular array does or does not provide > storage > > for objects of other types do sound useful. > > Thanks a lot for explanation! > I am adding Martin Sebor to CC. Perhaps you can fix the problem with > std::byte, and signed char to imply typeless storage and ideally also > add an attribute? This seem too deep into C++ FE details for me. >
I've fixed is_byte_access_type; now we shouldn't treat arrays of signed char as typeless storage. I don't have time to add the attribute in stage 1. Jason
