On Fri, Aug 05, 2022 at 02:51:14PM +0000, Klemens Nanni wrote: > On Fri, Aug 05, 2022 at 08:08:17AM -0600, Theo de Raadt wrote: > > I struggle to see any value of this concept: If you put a cast in-line > > in the code, as a coder you can know what it means. But if you abstract > > the typecast to some function in a header file, how do you remember > > that it only does a typecast, and doesn't do something else? I think this > > is a foolish abstraction without value. > > satosin(), sin6tosa(), etc. are convenient helpers to avoid manually > casting all over the place. > > struct sockaddr aka. sa, struct sockaddr_in6 aka. sin6, etc. are well > known abbreviations in networking code. > > I argue you can't get familiar with networking code without knowing what > these mean, so you remember them because they are so commonly used. > > Imho, the same can apply to *toc*(). > > Alternatively, we can expand usages of existing *to*() calls into plain > casts and add const where required to constify functions, but that seems > like a step backward to me as it makes code overly verbose.
We added the inline functions for these typecasts to add a minimal level of error protection. Now where do we hit const problems? I have not seen such issues and I wonder if those just come from overzealous use of const arguments to functions. -- :wq Claudio
