On Thu, Jun 04, 2020 at 04:19:03PM -0500, Gustavo A. R. Silva wrote: > On Thu, Jun 04, 2020 at 01:25:26PM -0700, Kees Cook wrote: > > On Thu, Jun 04, 2020 at 01:21:23PM -0500, Gustavo A. R. Silva wrote: > > > Yeah. My reasoning for is that it will take a while --at least one > > > development cycle more-- to completely get rid of all the 0/1-arrays. > > > > Right -- but we need a place to point people when we tell them "please > > don't use 0-byte and 1-byte arrays", and the deprecated.rst is the place > > for that. > > > > Having it in deprecated.rst once they're all gone only serves to explain > > why various compiler flags are enabled, etc. But while they're being > > removed, it serves as a single place to document the issue (as in, much > > of the flex-array patch commit log "boilerplate" can actually be > > repeated in deprecated.rst. > > > > > But I think we can add this note while I continue working on the flexible-array > > > conversions. Once that work is complete, I can go back and update the > > > documentation. :) > > > > > > What do you think? > > > > I think we need to document it at the beginning of the work (and I > > should have asked for this earlier). So let's just add a new section on > > dynamic array usage, etc. It can include a note about struct_size() as > > an example for why 1-byte arrays are so weird. :) > > > > Got ya. :) > > One last thing... I was thinking on adding such section (dynamic array > usage) to coding-style.rst, explaining how to use struct_size() and > transform the different open-coded versions we currently have in the > kernel, e.g. I have seen people use offsetof() --and sometimes open-coded > versions of sizeof_field()-- and its open-coded version to do arithmetic > in allocator arguments. Yeah, that sounds good to me! -Kees > > Thanks > -- > Gustavo > -- Kees Cook
