Alexander Bluhm <[email protected]> wrote: > On Fri, Aug 05, 2022 at 09:03:03AM -0600, Theo de Raadt wrote: > > But I also disagree with the idea of wrapping a trivial piece of C into > > a function located in another header file > > I added many of them a few years ago. We have them for all sockaddr > derivates. They are handy when doing network programming.
But I keep hearing "copied from NetBSD". > The advantage is that they check the input type. When you do > satosin(something) the compiler checks that someting is a sockaddr. > ((struct sockaddr_in *)something) will convert anything. It is an > additional layer of type protection. I think there are also disadvantages. For it to be an advantage, it must have actually helped at least once. Did it find any pieces of code casting a struct mbuf * to a sockaddr *, or similar? Or did it actually find zero, because programmers aren't that sloppy? Should we mandate this development practice in all of userland -- that you may not use C casting directly inline, as it is an unsafe programming practice, and must create helper functions in a .h file, and then use that? I am quite sick of pointless abstraction --- I think the tradeoff being made here is that simple understanding of single lines of code is being damaged.
