On Thu, May 19, 2016 at 07:33:50AM +0200, Vincent Bernat wrote: > ??? 18 mai 2016 22:56 +0200, Pavlos Parissis <pavlos.paris...@gmail.com> : > > >> Also, where is the bugtracker for haproxy? I can file a report if you > >> want to save time. > > > > As far as I know there isn't any bugtracker. Posting problems in this > > ML is enough to kick the investigation. So far this model works quite > > well > > Yes, Willy will notice the patch at some point and maybe merge it if > he's OK with it.
Exact and here 1000 persons can read the discussions, while bug trackers generally tend to be limited to a few interested readers. I like bug trackers for complex bugs that take months or years to be fixed though. Vincent, I was the one introducing htonll() and I did a mistake. I thought nobody would have it and as you saw, OSX proved me wrong, just like Solaris 11 now. Other OSes will follow and we'll get annoyed again once a libc decides to define _htonll() for its own use. Usually when there's a risk of symbol conflict, we prefix the offending functions by "my_" to clearly state that they are our own implementation and that while we try to have the same API there's no guarantee for this. Here I should have done this as well. I'd rather just rename the function, its two call places and get rid of the #ifndef. If you're interested in updating your patch for this I'll happily apply it. Otherwise I can do it myself to learn my lesson :-) Cheers, Willy
