elimination to our bytecode compiler. Also iterate it to a fixpoint.
Last, add a total instruction counter during bootstrap so we can easily
see how many instructions are in the core library.
These simple passes were factored out of some more involved bytecode
optimization work as easy wins without much code.
Some further research also suggests that this is well know limitation of
winsock and failure to call this in combination with ConnectEx can be a
problem.
However, I cannot reproduce locally on my windows machine. Searching
suggests a timing error within the network stack - if we call net/
functions before the connect is actually setup, it will be in an invalid
state.
* Fix a couple of imprecisions in the file/ docs
The `+` flag to `(file/open)` was incorrectly documented as being for
appending. Instead, this allows to read to files opened with `:w` or
`:a`, and to write to files opened with `:r`. This is the same as the
`+` flag in `fopen(3)`.
The `(file/seek)` function was documented as having both `whence` and
`n` as optional arguments. It also didn't say what the default for `n`
was. Anyway, this doesn't make sense, as a default of `:cur` and `0`
would effectively make `(file/seek f)` a no-op. I also amended a test so
both `(file/seek f :set 0)` and `(file/seek f :set)` are covered and
checked to move to the beginning of the file.
* Remove useless check for argc >= 2
We already determined it is between 2 and 3 with `janet_arity(argc, 2, 3)`.
* Dump args in assertion
* Unroll loop in test
* Differentiate failure messages
How about we resolve through the special host name "localhost." instead of assuming that the loopback interface is bound to 127.0.0.1 (which might not be the case, especially in FreeBSD jails)?
See RFC6761 for how "localhost." is treated, especially:
Name resolution APIs and libraries SHOULD recognize localhost
names as special and SHOULD always return the IP loopback address
for address queries and negative responses for all other query
types. Name resolution APIs SHOULD NOT send queries for
localhost names to their configured caching DNS server(s).
Add testcase for os/shell to test/suite-ev.janet
While we may not want to completely deprecate os/shell, we should at
least try to redirect users to better and safer interfaces like
os/execute.
I encountered this issue with `janet -e '(os/shell "echo")'` on Mac, system malloc lib will complain as follows:
```
janet(42817,0x7ff854547780) malloc: *** error for object 0x60000000b730: pointer being freed was not allocated
janet(42817,0x7ff854547780) malloc: *** set a breakpoint in malloc_error_break to debug
```
So I followed the suggestion and here's the backtrace:
```
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
* frame #0: 0x00007ff810cb6883 libsystem_malloc.dylib`malloc_error_break
frame #1: 0x00007ff810ca76d3 libsystem_malloc.dylib`malloc_vreport + 761
frame #2: 0x00007ff810caab31 libsystem_malloc.dylib`malloc_report + 151
frame #3: 0x0000000100025402 janet`janet_ev_default_threaded_callback(return_value=JanetEVGenericMessage @ 0x00007ff7bfefad90) at ev.c:2412:13 [opt]
frame #4: 0x0000000100024b1f janet`janet_loop1_impl [inlined] janet_ev_handle_selfpipe at ev.c:1643:13 [opt]
frame #5: 0x0000000100024ac9 janet`janet_loop1_impl(has_timeout=<unavailable>, timeout=0) at ev.c:2028:13 [opt]
frame #6: 0x0000000100024714 janet`janet_loop1 at ev.c:1588:13 [opt]
frame #7: 0x00000001000497f5 janet`janet_loop_fiber at ev.c:1609:41 [opt]
frame #8: 0x00000001000497b3 janet`janet_loop_fiber(fiber=0x0000600002903790) at run.c:150:5 [opt]
frame #9: 0x0000000100075266 janet`main(argc=<unavailable>, argv=0x00007ff7bfeff210) at shell.c:1284:14 [opt]
frame #10: 0x00007ff810b1041f dyld`start + 1903
```
Found out that it's actually a missing break in the code which leads to double free.
BTW, I'm thinking that if we can implement a debug allocator to be used in the test, so maybe this kind of bugs can be captured earlier.
Change-Id: I74d324b70b39ddc7d6f509b0382e2be36a6a6964
Signed-off-by: Tw <tw19881113@gmail.com>
on 32 bit systems in some cases.
Since most internal arrays in Janet have 32 bit limits, this is is not
hit in practice on 64 bit systems, except in cases of user input. Apply
a fix more generally to simply avoid the issue by coding "defensively".
Some applications are not strictly needed.
Calvin Rose