Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#211 closed defect (fixed)

(review) emergency patch: disable /dev/poll in ASIO

Reported by: jinmei Owned by: jinmei
Priority: high Milestone: 04. 2nd Incremental Release: Early Adopters
Component: b10-auth Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity:
Sub-Project: Feature Depending on Ticket:
Estimated Difficulty: Add Hours to Ticket:
Total Hours: Internal?:


Please some review the attached patch. It will fix the build error reported by the bot:

Note that I simply disable /dev/poll rather than lossen the warning level. See the comment for the reason. I also made a minor change to the kqueue case so that the sytanx for these two cases looks consistent.

I believe this is quite trivial, and I confirmed this work on a Solaris machine. But I'm trying to get it reviewed just in case.

If I don't hear something soon (within 6 hours or so?), I'll commit this change to trunk anyway.


Attachments (1) (1.7 KB) - added by jinmei 10 years ago.

Download all attachments as: .zip

Change History (4)

Changed 10 years ago by jinmei

comment:1 follow-up: Changed 10 years ago by each

  • Owner changed from UnAssigned to jinmei
  • Status changed from new to assigned

Looks fine, go ahead and merge.

I must say, I'm starting wonder if using -Werror while also relying on third-party headers is simply a bad idea... :(

comment:2 in reply to: ↑ 1 Changed 10 years ago by jinmei

  • Resolution set to fixed
  • Status changed from assigned to closed

Replying to each:

Looks fine, go ahead and merge.

THanks, committed (r1992).

I must say, I'm starting wonder if using -Werror while also relying on third-party headers is simply a bad idea... :(

The main problem with ASIO is that we actually include the "implementation", not just definitions that header files are normally expected provide. The "implementation" part of ASIO brought these troubles; otherwise we'd have had the same errors with boost.asio or sqlite3, etc. So, that's pretty specific to the non boost version ASIO, not a generic problem of relying on third-party headers with -Werror.

IMO, there shouldn't be an easy excuse to drop stronger warnings or dropping -Werror (I believe the former is obvious. It should also apply to -Werror because otherwise I'm sure we'd tend to ignore them).

I belive the middle term solution for this specific problem is to do essentially the same thing as boost.asio: providing a wrapper layer to ASIO as a separate internal library and limiting the level of warnings (or, if there's no other solution, disable -Werror) only within that wrapper. Other BIND 10 module should still use and benefit from the full strength of compiler warnings and -Werror.

comment:3 Changed 10 years ago by shane

  • Component changed from Unclassified to b10-auth
Note: See TracTickets for help on using tickets.