Hi David,
-Wsizeof-pointer-div isn't required by the standard, so any compiler other than gcc or clang is not required to emit anything to the user. In such compilers, the security risk would still be there and would be up to the maintainers' willingness to implement such feature (or developers' to provide their own safe ARRAY_SIZE macro, if possible). IMHO, the standard should find a way to detect this situation at compile-time, which is the reason why I though a new keyword (_Lengthof) would provide better semantics than status quo and a way to emit a meaningful diagnostic message if being incorrectly used. However, I would like _Typeof/typeof + <stdtypeof.h> to be added to the standard too, although I am not sure whether this has been already suggested to the committee (if so, with no success). Could you please help me bringing up reasons why it should be proposed to the committee? I would prefer _Typeof over C++'s decltype to avoid confusion among users. C and C++ compatibility is already too complex to provide yet another keyword that has slightly different behavior depending on the language. OTOH, I see no suggestions regarding the second proposal (static compound literals inside body functions). Do you find this proposal acceptable? Thank you very much for your feedback. -- Xavier Del Campo Romero May 29, 2020, 08:06 by david.br...@hesbynett.no: > On 28/05/2020 23:01, Xavier Del Campo Romero via Gcc wrote: > >> Hello gcc team, >> >> I have sent the following proposals to the committee, but they require them >> to be implemented at least into two major compilers, so I am proposing them >> to be implemented into gcc. This is going to be a rather lengthy e-mail, so >> TL;DR: >> >> Proposal 1: New pointer-proof keyword _Lengthof to determine array length >> Motivation: solve silent bugs when a pointer is accidentally used instead of >> an array >> > > In gcc, the simple "#define ARRAY_SIZE(a) sizeof (a) / sizeof *(a)" gives a > compile-time warning if passed a pointer, since the introduction of > "-Wsizeof-pointer-div" in -Wall in gcc 8. > > I am not convinced that anyone who would be careful enough in their coding to > use such a new "_Lengthof" feature would not already be using "-Wall" at > least. So for gcc, the new keyword would, I think, be useless. And for any > compiler without an equivalent warning (clang has it from version 7), it > would likely to be easier to add the warning rather than the keyword. > > Many people have figured out alternative "ARRAY_SIZE" macros that work with > existing compilers and give compile-time warnings on naked pointers. But > like your suggestion below, they rely on compiler extensions such as gcc's > "typeof". > > > So my counter-proposal for you would be to recommend gcc's "typeof" as a new > keyword (spelt "_Typeof", with "typeof" as a macro in <stdtypeof.h>, in solid > C tradition). > > Then you have a feature that has a long-established history in two major > compilers (gcc and clang, at least), has been massively used in real-world > code for decades, and has a huge range of useful use-cases. Get "typeof" into > the C standards and many people will thank you! And then your _Lengthof > becomes a simple macro that can be put in a standard header file, and needs > no established implementation to be acceptable. (And you don't need any help > from gcc or clang, except perhaps for describing the details of the semantics > of "typeof".) >
