Hacker News new | past | comments | ask | show | jobs | submit login

It's a limitation off the proposal, sure.

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.

Now you're referring to better designs, which is great. Have the best of both worlds if that's possible.

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. If it was that proposal or nothing, that proposal would be much better than nothing, despite the forced code changes to use it.




> 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?


The same way people switch to safe string functions and recompile?

Gradually, for one.


> Gradually, for one.

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?


Probably a while. But that doesn't stop the safety from being in the other 95% of the program.

And again, I wasn't comparing to any other implementations, because you hadn't brought them up yet!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: