`map_desired_position` does not return the actual position, probing must
be done afterwards to figure out the real position. `map_entry` did not
do this for the returned key pointer so it could point to the wrong key
if probing was done.
Now using any thread-local variables with -no-crt enabled
will cause a compiler error, unless -no-thread-local is
given.
Also fixed a minor typo in a comment.
The main motivation for this is to have sinergy with flags parsing, currently
flags for a sockaddr returns a net.Host_Or_Endpoint, but we can't just dial
from it since there isn't a variant.
Consider the following:
```
Options :: struct {
target: net.Host_Or_Endpoint `args:"pos=0,required" usage:"host:port"`,
}
before :: proc() -> (sock: net.TCP_Socket, err: net.Network_Error) {
opt: Options
flags.parse_or_exit(&opt, os.args)
switch t in opt.target {
case net.Host:
sock, err = net.dial_tcp(t.hostname, t.port)
case net.Endpoint:
sock, err = net.dial_tcp(t)
}
return
}
after :: proc() -> (sock: net.TCP_Socket, err: net.Network_Error) {
opt: Options
flags.parse_or_exit(&opt, os.args)
sock, err = net.dial_tcp(opt.target)
return
}
```
For completion, add dial_tcp_from_host() and define the upper functions in terms
of the newly added ones, cuts one repeated block, now:
from_hostname_and_port_string is parse + from_host_or_endpoint
from_hostname_with_port_override is parse + override + from_host_or_endpoint
from_host is to_endpoint + from_endpoint
from_host_or_endpoint is from_endpoint or from_host
os.args is never freed, while this is an insignificant leak, it is a bit
annoying as it makes valgrind complain:
==234270== Memcheck, a memory error detector
==234270== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==234270== Using Valgrind-3.24.0 and LibVEX; rerun with -h for copyright info
==234270== Command: ./wc /tmp/mulumulu
==234270==
1 8 58 /tmp/mulumulu
==234270==
==234270== HEAP SUMMARY:
==234270== in use at exit: 47 bytes in 1 blocks
==234270== total heap usage: 5 allocs, 4 frees, 4,195,875 bytes allocated
==234270==
==234270== 47 bytes in 1 blocks are possibly lost in loss record 1 of 1
==234270== at 0x484BC13: calloc (vg_replace_malloc.c:1675)
==234270== by 0x402E49: runtime._heap_alloc-769 (in /d/learn-odin/wc/wc)
==234270== by 0x40A8D7: runtime.heap_alloc (in /d/learn-odin/wc/wc)
==234270== by 0x436E9D: runtime.heap_allocator_proc.aligned_alloc-0 (in /d/learn-odin/wc/wc)
==234270== by 0x4022DC: runtime.heap_allocator_proc (in /d/learn-odin/wc/wc)
==234270== by 0x4165E0: runtime.make_aligned-22560 (in /d/learn-odin/wc/wc)
==234270== by 0x41F6D0: runtime.make_slice-22340 (in /d/learn-odin/wc/wc)
==234270== by 0x40156B: os._alloc_command_line_arguments-4679 (in /d/learn-odin/wc/wc)
==234270== by 0x4011AF: __$startup_runtime (in /d/learn-odin/wc/wc)
==234270== by 0x406F17: main (in /d/learn-odin/wc/wc)
==234270==
==234270== LEAK SUMMARY:
==234270== definitely lost: 0 bytes in 0 blocks
==234270== indirectly lost: 0 bytes in 0 blocks
==234270== possibly lost: 47 bytes in 1 blocks
==234270== still reachable: 0 bytes in 0 blocks
==234270== suppressed: 0 bytes in 0 blocks
==234270==
==234270== For lists of detected and suppressed errors, rerun with: -s
==234270== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
With the fix the leak is gone, tested on linux only.
While here, also make _alloc_command_line_arguments() private.
