On 03/01/2016 11:41 PM, Paul Eggert wrote: > On 03/01/2016 02:16 PM, Florian Weimer wrote: >>> Why not use a flexible array member for this? >> For which part, and how exactly? > > Something like the attached patch, say. (Totally untested.) > >> You can't put a flexible array member into a transparent union. > > That's OK. Any such usage of struct dirent would be unportable anyway. > >> If you mean to add some zero-width padding member at the end of the >> struct, after the d_name member, then I'm worried that makes overrunning >> the d_name array member even more undefined than it already is. > > No, no padding member, just use C99 the way it was designed. This > should improve overrun detection in programs like valgrind. With glibc's > current definition these programs can be fooled into thinking that > struct dirent accesses are invalid (outside of array bounds) when they > are actually OK, so people shut off array-bounds checking. If we used > flexible array members, valgrind etc. should know that the array's upper > bound is unknown and should not issue so many false alarms, so people > can leave bounds checking on. I don't think valgrind can see the difference, but you are correct in principle (this is essentially the “undefined” part I was worried about). Unfortunately, GCC does not produce a warning for taking the size of a struct with a flexible member, or for using it in a non-pointer declarator, so it does only half of what we want. And at the cost of changing sizeof (struct dirent), which can't be a good thing. > If flexible arrays are no-go for some reason, I suppose we could use > 'char 'd_name[SIZE_MAX - 1000];' instead. That should get peoples' > attention. :-) GCC refuses to compile the type definition, not just declarations. Refusing declarations with an error would break quite a lot of existing configure tests. struct dirent d; int z; z - d.d_ino; is a common idiom to check for struct members. Florian -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
