Some invalid handle values are -1 or INVALID_HANDLE_VALUE, hence our
handle template has a specific invalid handle value parameter we should
always test against. Time and again, I find my code simply comparing
handle against zero.
Signed-off-by: Simon Rozman <simon@rozman.si>
The handle validation is done with valid() method now, so using operator
T to auto-retrieve object handle should not provide ambiguities any
more. As long as we remember to use valid() for testing!
Signed-off-by: Simon Rozman <simon@rozman.si>
read() blocks when there is no more data to read. However, we do need
to loop when read is divided into blocks.
Signed-off-by: Simon Rozman <simon@rozman.si>
Looping ReadFile() system call is Windows-specific. POSIX systems don't
need this. In fact: with pipes using buffered streams, this blocks the
read until one full buffer of data is available.
Signed-off-by: Simon Rozman <simon@rozman.si>
Where test expression is already or almost boolean type, using ternery
operator is excessive and possibly more difficult to read.
Signed-off-by: Simon Rozman <simon@rozman.si>
Code analysis got quite good and we'd better keep warnings on our radar.
Either:
1. Research and resolve the reason for the warning.
2. Remove silencing and let code analysis complain.
3. Comment why some warning silencing is there.
Signed-off-by: Simon Rozman <simon@rozman.si>
When exception processing is unwinding the stack, any exception thrown
in destructors end up std::terminate()-in our process.
Since all workarounds to report errors from destructors seems an
overkill, and the only important place where we should notify the user
about a failure is the stdex::stream::cache::~cache() (data loss occurs
when failure happens here), and if we'd throw in stdex::stream::cache::
~cache(), our process would get terminated anyway so the data loss is
inevitable, let's just silence this for now and come up with a better
solution later if we get smarter anytime in the future.
Signed-off-by: Simon Rozman <simon@rozman.si>
char16_t is not exactly the wchar_t on Windows. char32_t is not exactly
the wchar_t on POSIX. Rather than selecting the appropriate variant,
polymorphism picked the template implementation of strncmp, strcpy and
strncpy. The one that does not convert UTF16 surrogate pairs against
their UTF32 representation.
Signed-off-by: Simon Rozman <simon@rozman.si>
