Adding a new network header with associated unit tests #506

keith-horton · 2025-02-25T07:20:43Z

Adding a new network header with associated unit tests.

keith-horton · 2025-02-25T07:54:49Z

@dunhor FYI: I started over with a new topic branch --> new PR. And now I'm no longer getting clang-format problems, and the winrt COM tests are passing :)

dunhor · 2025-02-26T17:34:46Z

@dunhor FYI: I started over with a new topic branch --> new PR. And now I'm no longer getting clang-format problems, and the winrt COM tests are passing :)

Sorry for the delayed response; been busy with a bunch of other things at the moment.

Regarding clang-format, I took a brief look at your other PR and it looks like you ran clang-format on all files & committed the result. This can have some unintended side effects because different versions of clang-format will format code differently. It's a little unfortunate, but it's not something we have much control over. To help alleviate pains here, we do two things. First, we prefer to use the version of clang-format that ships with Visual Studio for consistency across developers. The second is that the CI machines leverage git clang-format to check to see if the change is formatted correctly. This is all described in the readme. The simplest thing to do is to run git clang-format yourself for formatting changes. If that's not feasible (e.g. you don't have LLVM installed), you'll have to do a bit more manual labor to ensure you only commit changes you made. Even with all this, it may still not be perfect if the version of Visual Studio on the CI machine isn't quite up to date. This is fine - we can ignore the formatting failure so long as the code is reasonably formatted.

Regarding the COM tests, it's been failing for a while, but typically passes after one (or two) re-runs. It's on my TODO list for when I get the time to dig into it. Hopefully this can be fixed with something as simple as a detour to make it more deterministic.

keith-horton · 2025-02-26T17:54:38Z

@dunhor FYI: I started over with a new topic branch --> new PR. And now I'm no longer getting clang-format problems, and the winrt COM tests are passing :)

Sorry for the delayed response; been busy with a bunch of other things at the moment.

Regarding clang-format, I took a brief look at your other PR and it looks like you ran clang-format on all files & committed the result. This can have some unintended side effects because different versions of clang-format will format code differently. It's a little unfortunate, but it's not something we have much control over. To help alleviate pains here, we do two things. First, we prefer to use the version of clang-format that ships with Visual Studio for consistency across developers. The second is that the CI machines leverage git clang-format to check to see if the change is formatted correctly. This is all described in the readme. The simplest thing to do is to run git clang-format yourself for formatting changes. If that's not feasible (e.g. you don't have LLVM installed), you'll have to do a bit more manual labor to ensure you only commit changes you made. Even with all this, it may still not be perfect if the version of Visual Studio on the CI machine isn't quite up to date. This is fine - we can ignore the formatting failure so long as the code is reasonably formatted.

Regarding the COM tests, it's been failing for a while, but typically passes after one (or two) re-runs. It's on my TODO list for when I get the time to dig into it. Hopefully this can be fixed with something as simple as a detour to make it more deterministic.

Thanks for the explanation!

Yes, this time I just did a git clang-format for edited files.
And the pipeline is happy :)

keith-horton · 2025-03-09T23:56:55Z

@dunhor : well, those COM tests decided to start failing after I clang-formatted network.h. :(

Any thoughts on how to move this PR forward? can I just force that test to try again?

dmachaj · 2025-03-10T18:35:13Z

@dunhor : well, those COM tests decided to start failing after I clang-formatted network.h. :(

Any thoughts on how to move this PR forward? can I just force that test to try again?

I think you should disable them to unblock yourself. Those tests have been far more trouble than they are worth. The original com_timeout PR had me spend about 5-10x as long writing the tests as I did the non-test code. And despite that they still aren't reliable enough. The code they are testing is relatively small and has already been validated so I think that would be ok.

Also, I'm unsure if it is interesting that the two failures are x64+Release. x86 isn't failing; Debug is not failing.

keith-horton · 2025-03-13T23:31:55Z

@dunhor : well, those COM tests decided to start failing after I clang-formatted network.h. :(
Any thoughts on how to move this PR forward? can I just force that test to try again?

I think you should disable them to unblock yourself. Those tests have been far more trouble than they are worth. The original com_timeout PR had me spend about 5-10x as long writing the tests as I did the non-test code. And despite that they still aren't reliable enough. The code they are testing is relatively small and has already been validated so I think that would be ok.

Also, I'm unsure if it is interesting that the two failures are x64+Release. x86 isn't failing; Debug is not failing.

Thanks!
I'll put ifdefs around them so folks can still run the tests locally if they want to verify these objects.

keith-horton · 2025-03-16T22:37:33Z

Looks like clang no longer wants to compile this:

FAILED: tests/app/CMakeFiles/witest.app.dir/__/FileSystemTests.cpp.obj
C:\PROGRA~1\LLVM\bin\clang-cl.exe /nologo -TP -DCATCH_CONFIG_FAST_COMPILE -DNOMINMAX -DWIL_FAST_BUILD -DWINAPI_FAMILY=WINAPI_FAMILY_PC_APP -ID:\a\1\s\include -imsvcD:\a\1\s\build\clang32debug\include -imsvcD:\a\1\s\tests.\workarounds\wrl -imsvcD:\a\1\s\build\clang32debug\vcpkg_installed\x86-windows\include -m32 /DWIN32 /D_WINDOWS /GR- /EHsc /Zi /Ob0 /Od /RTC1 -std:c++17 -MDd /W4 /WX -Wno-missing-field-initializers -Wno-language-extension-token -Wno-c++17-attribute-extensions -Wno-gnu-zero-variadic-macro-arguments -Wno-extra-semi -Wno-self-assign-overloaded -Wno-self-move -mcx16 -fno-delayed-template-parsing /YuD:/a/1/s/build/clang32debug/tests/app/CMakeFiles/witest.app.dir/cmake_pch.hxx /FpD:/a/1/s/build/clang32debug/tests/app/CMakeFiles/witest.app.dir/./cmake_pch.cxx.pch /FID:/a/1/s/build/clang32debug/tests/app/CMakeFiles/witest.app.dir/cmake_pch.hxx /showIncludes /Fotests\app\CMakeFiles\witest.app.dir__\FileSystemTests.cpp.obj /Fdtests\app\CMakeFiles\witest.app.dir\ -c -- D:\a\1\s\tests\FileSystemTests.cpp
In file included from D:\a\1\s\tests\FileSystemTests.cpp:25:
D:\a\1\s\include\wil/stl.h(216,39): error: identifier '_zv' preceded by whitespace in a literal operator declaration is deprecated [-Werror,-Wdeprecated-literal-operator]
216 | constexpr zstring_view operator"" _zv(const char* str, std::size_t len) noexcept
| ~~~~~~~~~~~^~~
| operator""_zv
D:\a\1\s\include\wil/stl.h(221,40): error: identifier '_zv' preceded by whitespace in a literal operator declaration is deprecated [-Werror,-Wdeprecated-literal-operator]
221 | constexpr zwstring_view operator"" _zv(const wchar_t* str, std::size_t len) noexcept
| ~~~~~~~~~~~^~~
| operator""_zv
2 errors generated.

keith-horton · 2025-03-17T00:15:49Z

Looks like clang no longer wants to compile this:

FAILED: tests/app/CMakeFiles/witest.app.dir//FileSystemTests.cpp.obj C:\PROGRA~1\LLVM\bin\clang-cl.exe /nologo -TP -DCATCH_CONFIG_FAST_COMPILE -DNOMINMAX -DWIL_FAST_BUILD -DWINAPI_FAMILY=WINAPI_FAMILY_PC_APP -ID:\a\1\s\include -imsvcD:\a\1\s\build\clang32debug\include -imsvcD:\a\1\s\tests.\workarounds\wrl -imsvcD:\a\1\s\build\clang32debug\vcpkg_installed\x86-windows\include -m32 /DWIN32 /D_WINDOWS /GR- /EHsc /Zi /Ob0 /Od /RTC1 -std:c++17 -MDd /W4 /WX -Wno-missing-field-initializers -Wno-language-extension-token -Wno-c++17-attribute-extensions -Wno-gnu-zero-variadic-macro-arguments -Wno-extra-semi -Wno-self-assign-overloaded -Wno-self-move -mcx16 -fno-delayed-template-parsing /YuD:/a/1/s/build/clang32debug/tests/app/CMakeFiles/witest.app.dir/cmake_pch.hxx /FpD:/a/1/s/build/clang32debug/tests/app/CMakeFiles/witest.app.dir/./cmake_pch.cxx.pch /FID:/a/1/s/build/clang32debug/tests/app/CMakeFiles/witest.app.dir/cmake_pch.hxx /showIncludes /Fotests\app\CMakeFiles\witest.app.dir\FileSystemTests.cpp.obj /Fdtests\app\CMakeFiles\witest.app.dir\ -c -- D:\a\1\s\tests\FileSystemTests.cpp In file included from D:\a\1\s\tests\FileSystemTests.cpp:25: D:\a\1\s\include\wil/stl.h(216,39): error: identifier '_zv' preceded by whitespace in a literal operator declaration is deprecated [-Werror,-Wdeprecated-literal-operator] 216 | constexpr zstring_view operator"" _zv(const char* str, std::size_t len) noexcept | ~~~~~~~~~~~^~~ | operator""_zv D:\a\1\s\include\wil/stl.h(221,40): error: identifier '_zv' preceded by whitespace in a literal operator declaration is deprecated [-Werror,-Wdeprecated-literal-operator] 221 | constexpr zwstring_view operator"" _zv(const wchar_t* str, std::size_t len) noexcept | ~~~~~~~~~~~^~~ | operator""_zv 2 errors generated.

I think it's related to this:
https://releases.llvm.org/20.1.0/tools/clang/docs/ReleaseNotes.html

The warning -Wdeprecated-literal-operator is now on by default, as this is something that WG21 has shown interest in removing from the language. The result is that anyone who is compiling with -Werror should see this diagnostic. To fix this diagnostic, simply removing the space character from between the operator"" and the user defined literal name will make the source no longer deprecated. This is consistent with CWG2521 https://cplusplus.github.io/CWG/issues/2521.html_.

keith-horton · 2025-03-17T00:19:10Z

Looks like clang no longer wants to compile this:
FAILED: tests/app/CMakeFiles/witest.app.dir//FileSystemTests.cpp.obj C:\PROGRA~1\LLVM\bin\clang-cl.exe /nologo -TP -DCATCH_CONFIG_FAST_COMPILE -DNOMINMAX -DWIL_FAST_BUILD -DWINAPI_FAMILY=WINAPI_FAMILY_PC_APP -ID:\a\1\s\include -imsvcD:\a\1\s\build\clang32debug\include -imsvcD:\a\1\s\tests.\workarounds\wrl -imsvcD:\a\1\s\build\clang32debug\vcpkg_installed\x86-windows\include -m32 /DWIN32 /D_WINDOWS /GR- /EHsc /Zi /Ob0 /Od /RTC1 -std:c++17 -MDd /W4 /WX -Wno-missing-field-initializers -Wno-language-extension-token -Wno-c++17-attribute-extensions -Wno-gnu-zero-variadic-macro-arguments -Wno-extra-semi -Wno-self-assign-overloaded -Wno-self-move -mcx16 -fno-delayed-template-parsing /YuD:/a/1/s/build/clang32debug/tests/app/CMakeFiles/witest.app.dir/cmake_pch.hxx /FpD:/a/1/s/build/clang32debug/tests/app/CMakeFiles/witest.app.dir/./cmake_pch.cxx.pch /FID:/a/1/s/build/clang32debug/tests/app/CMakeFiles/witest.app.dir/cmake_pch.hxx /showIncludes /Fotests\app\CMakeFiles\witest.app.dir\FileSystemTests.cpp.obj /Fdtests\app\CMakeFiles\witest.app.dir\ -c -- D:\a\1\s\tests\FileSystemTests.cpp In file included from D:\a\1\s\tests\FileSystemTests.cpp:25: D:\a\1\s\include\wil/stl.h(216,39): error: identifier '_zv' preceded by whitespace in a literal operator declaration is deprecated [-Werror,-Wdeprecated-literal-operator] 216 | constexpr zstring_view operator"" _zv(const char* str, std::size_t len) noexcept | ~~~~~~~~~~~^~~ | operator""_zv D:\a\1\s\include\wil/stl.h(221,40): error: identifier '_zv' preceded by whitespace in a literal operator declaration is deprecated [-Werror,-Wdeprecated-literal-operator] 221 | constexpr zwstring_view operator"" _zv(const wchar_t* str, std::size_t len) noexcept | ~~~~~~~~~~~^~~ | operator""_zv 2 errors generated.

I think it's related to this: https://releases.llvm.org/20.1.0/tools/clang/docs/ReleaseNotes.html

The warning -Wdeprecated-literal-operator is now on by default, as this is something that WG21 has shown interest in removing from the language. The result is that anyone who is compiling with -Werror should see this diagnostic. To fix this diagnostic, simply removing the space character from between the operator"" and the user defined literal name will make the source no longer deprecated. This is consistent with CWG2521 https://cplusplus.github.io/CWG/issues/2521.html_.

Yep - that should be it.
I use ReSharper - and it flagged that exactly. (with the required fix :))

keith-horton · 2025-03-17T02:15:10Z

And we get another clang compiler issue:

FAILED: tests/app/CMakeFiles/witest.app.dir/__/ResourceTests.cpp.obj
C:\PROGRA~1\LLVM\bin\clang-cl.exe /nologo -TP -DCATCH_CONFIG_FAST_COMPILE -DNOMINMAX -DWIL_FAST_BUILD -DWINAPI_FAMILY=WINAPI_FAMILY_PC_APP -ID:\a\1\s\include -imsvcD:\a\1\s\build\clang32debug\include -imsvcD:\a\1\s\tests.\workarounds\wrl -imsvcD:\a\1\s\build\clang32debug\vcpkg_installed\x86-windows\include -m32 /DWIN32 /D_WINDOWS /GR- /EHsc /Zi /Ob0 /Od /RTC1 -std:c++17 -MDd /W4 /WX -Wno-missing-field-initializers -Wno-language-extension-token -Wno-c++17-attribute-extensions -Wno-gnu-zero-variadic-macro-arguments -Wno-extra-semi -Wno-self-assign-overloaded -Wno-self-move -mcx16 -fno-delayed-template-parsing /YuD:/a/1/s/build/clang32debug/tests/app/CMakeFiles/witest.app.dir/cmake_pch.hxx /FpD:/a/1/s/build/clang32debug/tests/app/CMakeFiles/witest.app.dir/./cmake_pch.cxx.pch /FID:/a/1/s/build/clang32debug/tests/app/CMakeFiles/witest.app.dir/cmake_pch.hxx /showIncludes /Fotests\app\CMakeFiles\witest.app.dir__\ResourceTests.cpp.obj /Fdtests\app\CMakeFiles\witest.app.dir\ -c -- D:\a\1\s\tests\ResourceTests.cpp
In file included from D:\a\1\s\tests\ResourceTests.cpp:4:
D:\a\1\s\include\wil/resource.h(1011,23): error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'wil::unique_struct<ThingToDestroy2, void (ThingToDestroy2::)() attribute((thiscall)), &CATCH2_INTERNAL_TEST_28()::ThingToDestroy2::destroy>' [-Werror,-Wnontrivial-memcall]
1011 | RtlZeroMemory(this, sizeof(this));
| ^
D:\a\1\s\include\wil/resource.h(917,9): note: in instantiation of member function 'wil::unique_struct<ThingToDestroy2, void (ThingToDestroy2::)() attribute((thiscall)), &CATCH2_INTERNAL_TEST_28()::ThingToDestroy2::destroy>::call_init' requested here
917 | call_init(use_default_init_fn());
| ^
D:\a\1\s\tests\ResourceTests.cpp(847,109): note: in instantiation of member function 'wil::unique_struct<ThingToDestroy2, void (ThingToDestroy2::)() attribute((thiscall)), &CATCH2_INTERNAL_TEST_28()::ThingToDestroy2::destroy>::unique_struct' requested here
847 | wil::unique_struct<ThingToDestroy2, decltype(&ThingToDestroy2::destroy), &ThingToDestroy2::destroy> other;
| ^
D:\a\1\s\include\wil/resource.h(1011,23): note: explicitly cast the pointer to silence this warning
1011 | RtlZeroMemory(this, sizeof(*this));
| ^
1 error generated.

keith-horton · 2025-03-17T02:21:53Z

And we get another clang compiler issue:

FAILED: tests/app/CMakeFiles/witest.app.dir//ResourceTests.cpp.obj C:\PROGRA~1\LLVM\bin\clang-cl.exe /nologo -TP -DCATCH_CONFIG_FAST_COMPILE -DNOMINMAX -DWIL_FAST_BUILD -DWINAPI_FAMILY=WINAPI_FAMILY_PC_APP -ID:\a\1\s\include -imsvcD:\a\1\s\build\clang32debug\include -imsvcD:\a\1\s\tests.\workarounds\wrl -imsvcD:\a\1\s\build\clang32debug\vcpkg_installed\x86-windows\include -m32 /DWIN32 /D_WINDOWS /GR- /EHsc /Zi /Ob0 /Od /RTC1 -std:c++17 -MDd /W4 /WX -Wno-missing-field-initializers -Wno-language-extension-token -Wno-c++17-attribute-extensions -Wno-gnu-zero-variadic-macro-arguments -Wno-extra-semi -Wno-self-assign-overloaded -Wno-self-move -mcx16 -fno-delayed-template-parsing /YuD:/a/1/s/build/clang32debug/tests/app/CMakeFiles/witest.app.dir/cmake_pch.hxx /FpD:/a/1/s/build/clang32debug/tests/app/CMakeFiles/witest.app.dir/./cmake_pch.cxx.pch /FID:/a/1/s/build/clang32debug/tests/app/CMakeFiles/witest.app.dir/cmake_pch.hxx /showIncludes /Fotests\app\CMakeFiles\witest.app.dir\ResourceTests.cpp.obj /Fdtests\app\CMakeFiles\witest.app.dir\ -c -- D:\a\1\s\tests\ResourceTests.cpp In file included from D:\a\1\s\tests\ResourceTests.cpp:4: D:\a\1\s\include\wil/resource.h(1011,23): error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'wil::unique_struct<ThingToDestroy2, void (ThingToDestroy2::)() attribute((thiscall)), &CATCH2_INTERNAL_TEST_28()::ThingToDestroy2::destroy>' [-Werror,-Wnontrivial-memcall] 1011 | RtlZeroMemory(this, sizeof(this)); | ^ D:\a\1\s\include\wil/resource.h(917,9): note: in instantiation of member function 'wil::unique_struct<ThingToDestroy2, void (ThingToDestroy2::)() attribute((thiscall)), &CATCH2_INTERNAL_TEST_28()::ThingToDestroy2::destroy>::call_init' requested here 917 | call_init(use_default_init_fn()); | ^ D:\a\1\s\tests\ResourceTests.cpp(847,109): note: in instantiation of member function 'wil::unique_struct<ThingToDestroy2, void (ThingToDestroy2::)() attribute((thiscall)), &CATCH2_INTERNAL_TEST_28()::ThingToDestroy2::destroy>::unique_struct' requested here 847 | wil::unique_struct<ThingToDestroy2, decltype(&ThingToDestroy2::destroy), &ThingToDestroy2::destroy> other; | ^ D:\a\1\s\include\wil/resource.h(1011,23): note: explicitly cast the pointer to silence this warning 1011 | RtlZeroMemory(this, sizeof(*this)); | ^ 1 error generated.

This apparently is also in the clang release notes:

Modified Compiler Flags
The -ffp-model option has been updated to enable a more limited set of optimizations when the fast argument is used and to accept a new argument, aggressive. The behavior of -ffp-model=aggressive is equivalent to the previous behavior of -ffp-model=fast. The updated -ffp-model=fast behavior no longer assumes finite math only and uses the promoted algorithm for complex division when possible rather than the less basic (limited range) algorithm.

The -fveclib option has been updated to enable -fno-math-errno for -fveclib=ArmPL and -fveclib=SLEEF. This gives Clang more opportunities to utilize these vector libraries. The behavior for all other vector function libraries remains unchanged.

The -Wnontrivial-memcall warning has been added to warn about passing non-trivially-copyable destination parameter to memcpy, memset and similar functions for which it is a documented undefined behavior. It is implied by -Wnontrivial-memaccess

…r warning nontrivial-memcall.

include/wil/network.h

dunhor · 2025-03-25T17:00:50Z

/AzurePipelines run

azure-pipelines · 2025-03-25T17:01:01Z

Azure Pipelines successfully started running 1 pipeline(s).

dunhor · 2025-03-25T17:01:28Z

Azure Pipelines successfully started running 1 pipeline(s).

Yay, it worked

include/wil/network.h

keith-horton · 2025-05-28T06:56:43Z

/AzurePipelines run

azure-pipelines · 2025-05-28T06:56:48Z

Commenter does not have sufficient privileges for PR 506 in repo microsoft/wil

keith-horton · 2025-05-28T06:57:49Z

/AzurePipelines run

@dunhor : can you run this command to kick off the CI pipeline? I tried and it said, "Commenter does not have sufficient privileges for PR 506 in repo microsoft/wil"

jonwis · 2025-05-28T16:00:55Z

/AzurePipelines run

azure-pipelines · 2025-05-28T16:01:08Z

Azure Pipelines successfully started running 1 pipeline(s).

dunhor · 2025-05-28T16:10:22Z

Thanks Jon.

FYI - I'm seriously contemplating moving to GitHub actions so we don't have this commenting requirement (for however long that lasts)

… changes

keith-horton · 2025-05-29T02:40:50Z

Thanks Jon.

FYI - I'm seriously contemplating moving to GitHub actions so we don't have this commenting requirement (for however long that lasts)

Thanks guys.

Turns out "git add *" + git clang-format --style file" didn't format these files. "scripts\format-changes.cmd upstream/master" didn't format these files.

But scripts\run-clang-format.cmd seems to have formatted them.

Would you mind restarting the CI pipeline? All other stages looked to have succeeded.

jonwis · 2025-05-29T05:31:05Z

If I ever get my act together with CMake, we can add a target that is "format check on every build."

"Coming soon"

jonwis · 2025-05-29T05:31:10Z

/azp run

azure-pipelines · 2025-05-29T05:31:21Z

Azure Pipelines successfully started running 1 pipeline(s).

dunhor · 2025-05-29T05:49:44Z

Turns out "git add *" + git clang-format --style file" didn't format these files. "scripts\format-changes.cmd upstream/master" didn't format these files.

There should be a comment in the main readme regarding this. The TL;DR is that different versions of clang-format will format the same code differently. This is why we suggest using git clang-format instead (and use it for CI validation) since running clang-format on the entire codebase may touch files/lines unrelated to your change which can be a pain to review and merge. Not to mention the fact that it's very specific to the version of clang-format running on your machine, which may differ from the version running on someone else's, including the CI machine, which is probably the source of the behavior you see (there's also a version of clang-format that ships with Visual Studio, which we prefer to use for consistency, and may play a role here).

That said, as long as you've formatted the code, that's all we really care about. If the CI fails because of inconsistent versions of clang-format, you can leave a comment and we can override that check because we know that it can be annoying and inconvenient to try and match things up exactly.

As an aside, one thing I've been wanting to do is throw something like a git diff into the pipeline so that the formatting differences are clear to anyone who looks, making an override decision easier or allowing the PR author to jut make the change themselves.

As a super aside, it's been on my wishlist for a while to add a command we can run that will format the code and commit the result. I just haven't had the time to look into it yet.

include/wil/network.h

…'tor to declaratively follow the rule-of-5

dunhor · 2025-06-02T16:03:21Z

/azp run

azure-pipelines · 2025-06-02T16:03:33Z

Azure Pipelines successfully started running 1 pipeline(s).

keith-horton · 2025-06-09T04:49:25Z

/azp run

[edit: heh, I tried]

azure-pipelines · 2025-06-09T04:49:32Z

Commenter does not have sufficient privileges for PR 506 in repo microsoft/wil

azure-pipelines · 2025-06-09T04:49:53Z

Command 'run [edit:' is not supported by Azure Pipelines. Supported commands help: Get descriptions, examples and documentation about supported commands Example: help "command_name" list: List all pipelines for this repository using a comment. Example: "list" run: Run all pipelines or specific pipelines for this repository using a comment. Use this command by itself to trigger all related pipelines, or specify specific pipelines to run. Example: "run" or "run pipeline_name, pipeline_name, pipeline_name" where: Report back the Azure DevOps orgs that are related to this repository and org Example: "where" See additional documentation.

keith-horton · 2025-06-09T04:51:00Z

@dunhor , @jonwis : do we need to kick this through the CI pipeline one more time?

(sorry, I merged with the master branch)

dunhor · 2025-06-09T15:56:56Z

/azp run

azure-pipelines · 2025-06-09T15:57:07Z

Azure Pipelines successfully started running 1 pipeline(s).

dunhor · 2025-06-09T15:57:48Z

@dunhor , @jonwis : do we need to kick this through the CI pipeline one more time?

(sorry, I merged with the master branch)

Kicked it off. If there's no other feedback by the end of the day I'll go ahead and squash & merge the PR

Adding a new network header with associated unit tests

14b4212

keith-horton mentioned this pull request Feb 25, 2025

Adding networking.h to provide RAII and iterator support for networking calls #497

Closed

keith-horton added 3 commits March 6, 2025 21:23

Merge branch 'master' into user/khorton/wil_network

234be40

Updates after applying the new header to a couple of real projects.

2a34cb3

clang-format

71c8795

marking the RPC COM test as local-only to avoid CI pipeline failures

09975ca

Fixing deprecated-literal-operator warning in stl.h

fafcb70

keith-horton added 2 commits March 16, 2025 23:16

Trying a fix for the clang nontrivial-memcall error

753d707

Fixing StoredCallContextInfo in tracelogging.h from the clang compile…

76c04a0

…r warning nontrivial-memcall.

jonwis reviewed Mar 17, 2025

View reviewed changes

include/wil/network.h Show resolved Hide resolved

include/wil/network.h Outdated Show resolved Hide resolved

include/wil/network.h Outdated Show resolved Hide resolved

keith-horton added 2 commits March 17, 2025 19:02

renaming the to-string functions from 'write' to 'format'

d133e79

Merge with parent.

b5d7674

jonwis previously approved these changes Mar 25, 2025

View reviewed changes