> I'm saying to deal with it. Change the code to be compatible. It's not that important to keep it the way it is.
> But when you were just pointing out that difficulty, my response is that it's a very small difficulty so that's not a big mark against the idea.
In what alternate timeline do we exist where HNers believe you can just recompile the entire world for the sake of any random program? Say you're a random user calling bind() or getpeername() in your OS's socket library. Or you're Microsoft, trying to secure a function like WSAConnect(). All of which are susceptible to overflows in struct sockaddr. Your proposal is "just move the length from 3rd parameter into the sockaddr struct" because "it's not that important to keep these APIs the way they are"?! How exactly do you propose making this work?
I can't believe you think changing the world isn't a big deal.
So say I'm on board and decide sockaddr Must Be Changed. Roughly how long do you think it will be from today before I can ship to my customers a program using the new, secure definition?
And how does the time and effort required compare against the more powerful implementation that's already out there?
> But when you were just pointing out that difficulty, my response is that it's a very small difficulty so that's not a big mark against the idea.
In what alternate timeline do we exist where HNers believe you can just recompile the entire world for the sake of any random program? Say you're a random user calling bind() or getpeername() in your OS's socket library. Or you're Microsoft, trying to secure a function like WSAConnect(). All of which are susceptible to overflows in struct sockaddr. Your proposal is "just move the length from 3rd parameter into the sockaddr struct" because "it's not that important to keep these APIs the way they are"?! How exactly do you propose making this work?