Does QUIC_UINT62 require the highest 2 bits to be 0?

[shit-lord]

I'm reusing ntstatus as my application's error code so I don't have to invent my own.
This does not work: msquic->ConnectionShutdown(Connection,QUIC_CONNECTION_SHUTDOWN_FLAG_NONE,STATUS_LOGON_FAILURE)
This does work: msquic->ConnectionShutdown(Connection,QUIC_CONNECTION_SHUTDOWN_FLAG_NONE,(uint32_t)STATUS_LOGON_FAILURE)

I guess the cause is STATUS_LOGON_FAILURE being sign extended to 64 bits, since NTSTATUS is just long. HRESULT faces the same issue, as it is also a signed type.

However, I think the api should not assume the highest 2 bits being 0. Its real type is 62 bits. The high 2 bits of its uint64_t carrier should be treated like garbage and discarded, just like the padding bytes of struct. Unless they are reserved bits so users must give a definite value for them.

[nibanks]

Does QUIC_UINT62 require the highest 2 bits to be 0?

Yes. For instance, see RESET_STREAM frame where Application Protocol Error Code is encoded as a variable-length integer. The encoding scheme QUIC uses leverages those two bits, so you can't use them.