# Final Release Note [WRITE /TLS](https://docs.yottadb.com/ProgrammersGuide/ioproc.html#write-command) does not set [$TEST](https://docs.yottadb.com/ProgrammersGuide/isv.html#test) in case no timeout was specified. In YottaDB releases r1.30 to r2.02, $TEST was set even in this case whereas it should have been set only if a timeout was specified. [#1136] # Description After merging GT.M V7.1-002, I noticed the following warning. ```c sr_unix/iosocket_tls.c:417:23: warning: result of comparison of constant 9223372036854775800 with expression of type 'int4' (aka 'int') is always true [-Wtautological-constant-out-of-range-compare] if (NO_M_TIMEOUT != msec_timeout) ~~~~~~~~~~~~ ^ ~~~~~~~~~~~~ ``` And this is because of new logic that was introduced in `sr_unix/iosocket_tls.c`, by GT.M V7.1-002, that compared a milli-second timeout value against the `NO_M_TIMEOUT` macro. This macro is a 4-byte value (`0x0007FFFE` = `524286` in decimal) in GT.M code but is an 8-byte value (`0x7FFFFFFFFFFFFFF8` = `9223372036854775800` in decimal) in YottaDB code. The compiler warning is therefore valid (as this huge value will always be not equal to `msec_timeout`) and needs to be fixed (I will take care of it as part of YDB!1652). But more importantly, I noticed that `iosocket_tls.c` had 9 usages like below (this is from the YDB master branch). ```c $ rg 'NO_M_TIMEOUT != ' sr_unix/iosocket_tls.c | head -1 172: if (NO_M_TIMEOUT != (msec_timeout * (uint8)NANOSECS_IN_MSEC)) ``` That is, we are comparing `NO_M_TIMEOUT`, which is a huge 8-byte value, against the milli-second timeout multiplied by `NANOSECS_IN_MSEC` which is `1,000,000`. And if they are not equal, we conclude that a timeout was specified. And the reason we can do this is because the caller function `iosocket_iocontrol()` had been passed a nanosecond timeout by the compiler and would have seen the `NO_M_TIMEOUT` value in case no timeout was specified. But it did a divide by `NANOSECS_IN_MSEC` before passing a milli-second timeout to `iosocket_tls()`. ```c sr_port/iosocket_iocontrol.c 249: iosocket_tls(option, (int)(nsec_timeout / NANOSECS_IN_MSEC), tlsid, password, extraarg); ``` All this is fine. But note that `NO_M_TIMEOUT` = `9223372036854775800` is only a multiple of 100 but not a multiple of `1,000,000`. That means, the division and multiplication by `NANOSECS_IN_MSEC` in the caller and the callee will cause it to eventually evaluate to the value `9223372036854000000` (because `/` operator will cause C to round down when dividing). That is, the last 6 digits would be 0. This is not the same as `NO_M_TIMEOUT` and so checks like in line 172 above will never succeed even if no timeout was specified in the `write /tls` command. What this means is that the `write /tls` command would treat all invocations as if a timeout was specified even if no timeout was specified. The documentation for [write /tls](https://docs.yottadb.com/ProgrammersGuide/ioproc.html#write-command) says the following. ``` WRITE /TLS(option[,[timeout][,tlsid[,[obfuscatedpassword][,cfg-file-options]]]]) If a timeout is specified for options "client" or "server", YottaDB sets $TEST to 1 if the command successfully completed or to 0 if it timed out. ``` The user-visible consequence of not specifying a timeout is that `$TEST` should not be set whether the command completed successfully or not. But because of `write /tls` treating all invocations as if a timeout was specified, we will end up modifying `$TEST` even if no timeout was specified. This is a regression in the YottaDB change to use nanosecond (instead of millisecond) timers (#388, commit 1ccb6b3e, which was released as part of YottaDB `r1.30`). I was also able to confirm this with a test case. # Draft Release Note `write /tls` does not set `$test` in case no timeout was specified. In YottaDB releases r1.30 to r2.02, `$test` was set even in this case whereas it should have been set only if a timeout was specified. [#1136]