On Wed Mar 19 00:33:33 2025 +0000, Elizabeth Figura wrote:
Sorry, let me clarify. According to my reading of the documentation alone—which is of course not to be trusted, but also isn't tested in this patch series—the parameters to WSALookupServiceBegin() are only filters. In particular, the flags LUP_CONTAINERS and LUP_NOCONTAINERS both exist. I would *assume* that specifying LUP_CONTAINERS causes only containers to be returned, LUP_NOCONTAINERS causes only services to be returned, and specifying neither flag means that both containers and services will be returned. Possibly this is not actually what happens. Actually, a similar issue is suggested by the documentation for the first parameter: the dwNameSpace parameter can be NS_ALL, which implies that having any unions at all in struct ws_lookup_service_ctx is problematic. This is not to say that we need to go as far as testing LUP_NOCONTAINERS or NS_ALL. In fact, I am inclined to suspect this patch goes to excessive lengths to future-proof the code. It's not like putting things in unions after the fact is generally that much of a problem, in my opinion. At the same time, I as a maintainer would not necessarily reject a future-proof design that I feel is sufficiently unobtrusive and/or likely to be necessary. But it's not clear that this design *is* going in the right direction; the documentation suggests it's not and it doesn't have any tests (even external informal ones) to contradict the documentation.
Ah. I've been relying on MSDN's Bluetooth specific [documentation for Winsock here](https://learn.microsoft.com/en-us/windows/win32/bluetooth/bluetooth-and-wsal...). According to that, `LUP_NOCONTAINERS` is entirely ignored (the docs explicitly say that any flags except for `LUP_CONTAINERS` and `LUP_FLUSHCACHE` are ignored for `NS_BTH`).
If flags to `WSALookupServiceBegin` are supposed to act like filters, the Bluetooth-specific functionality for this method is completely different. Device and service discovery are mutually exclusive, and which one of the two is going to happen seems to be set in stone after the first `WSALookupServiceBegin` call.
I've added to the `protocol.c` tests in the latest revision which demonstrate this behavior a little more clearly.
As to `NS_ALL`, you're right, I'm not sure how this fits in with that. But given `NS_BTH`'s behavior, I'm not even sure if `NS_ALL` would include Bluetooth data in the first place.