Disclaimer: Based mostly on my C++ experience with this kind of problem, did
not run into it with Nim and can't test this second.
> If you're including other people code in your project you just have to trust
> them in the same way you trust it to work.
Linus Torvalds has said more than once th
> Yes, this can become a security problem in some cases to inject unwanted
> behaviours in existing code.
before considering this "security concern", consider the fact that if I wanted
to anything harmful I could just write this into my module:
static:
staticExec("rm **/*.*")
Replying to myself...
In order for Alice to prevent such situation, she could force herself to
enforce full module prefix in proc calls with [module qualified
access](https://nim-lang.org/docs/manual.html#modules-from-import-statement).
from A import nil
from B import nil
There's no need for such complicated stuff, just remember you can run almost
any Nim code at compile-time ;)
Yes, this can become a security problem in some cases to inject unwanted
behaviours in existing code.
Programmer Alice uses 2 libraries A and B written by two different authors. A
provides a general `proc foo[X](x: X)` that Alice uses in her code. She tests
her program and releases version 1.
I'm ambivalent about that issue of not knowing where things are defined in nim.
On the one hand, I like how clean the code reads without fully qualifying procs
from their modules. On the other, if I don't have complete knowledge of all
modules, then I've little idea where a particular proc/templ
Fantastic explanation; Thank you so much for taking the time to explain this
and look into the issue. I had forgotten that, of course, strings are smart
objects that check their length, and have a `setLen()` for cases like this.
:facepalm:
Humorously, I wrote an entire tool predicated on my fau
I didn’t use `create` but reading the documentation it is clear that the
parameter `size`, whose default value is 1, is the number of elements to
allocate. That is, for a string, 8 bytes for a pointer and, under the hood, 8
bytes for the length, 8 bytes for the capacity and 0 bytes for the actua
Sorry, it should be: Where or how can I find `string.create` in the nim-docs?
I think I found it here:
[https://nim-lang.org/docs/system.html#create%2Ctypedesc](https://nim-lang.org/docs/system.html#create%2Ctypedesc)
Reading this I think, that the example code wrong anyway, because
sizeof(string) is 8 (not 1).
The documentation for `create` (cited above) can be a bit misleading. I tried
to read it in context, but could not find it.
Where or how can I find `create.string` in the nim-docs?
When you allocate the string using `create`, it is initialized with zeroes. So
its capacity and its length are null as if it was assigned `""`. Then, if you
assign globally the string, it works, but not if you assign each element
individually.
But this works:
# test.nim
proc m
> Maybe manually allocated strings like this can only be achieved using
> `UncheckedArray[char]`?
It depends on your use case. `newString()` also supports taking a length if all
you want is to create a pre-allocated buffer.
Maybe manually allocated strings like this can only be achieved using
UnchedArray[char]?
# test.nim
proc main =
let str = "hello"
var sptr = UncheckedArray[char].create(str.len)
for i in 0 ..< str.len:
sptr[][i] = str[i]
echo sptr[]
when i
@juancarlospaco Thanks. Yes, that's the error message. But I'm using `create`,
which the docs state:
create(): The block is initialized with all bytes containing zero,
so it is somewhat safer than createU.
Run
and I can definitely use `copyMem` with the a
I dont troubleshoot the code, but from a quick look, basically the pointer is
empty uninitialized.
Kinda like doing `nil[1] = 'e'`
Hi, I'd appreciate help understanding why the below example fails. Thanks for
looking!
# test.nim
proc main =
let str = "hello"
var sptr = string.create(str.len)
#copyMem(sptr, unsafeAddr str, str.len) # this works
#sptr[] = str # this also works
# b
17 matches
Mail list logo
