Mirror of forum.nim-lang.org

6370 :: Best Nim translation of C {void*, size_t} struct

• snej (orginal) [2020-05-23T01:53:05+02:00] view original

  I'm working on Nim glue to a C API that uses struct iovec a lot as a parameter type — a generic (pointer, length) tuple indicating a range of memory to read or write.

  IIRC, a Nim openarray[uint8] is passed the same way as an iovec: as the address of the first byte, then the length. So if I changed the iovec parameters in the bridged C declarations to openarray[uint8], to make them easier for me to use, would that work? And just as importantly, is this something that can be counted on to work in the future, either because it's official or because too many projects do it already?

  Or is there an even better way to do it?

  —Jens

---

• Araq (orginal) [2020-05-23T07:40:50+02:00] view original

  I would use openarray[uint8] too. Strictly speaking though Nim uses a Nim int (== ssize_t) as the length information and so it's incompatible for arrays which contain more than 2 billion elements (on a 32 bit machine). Never happens.

---

• snej (orginal) [2020-05-28T19:33:20+02:00] view original

  Just to make sure you're answering the exact question I asked :) — if I declare a C proc that takes an openarray, when Nim calls that function does it pass that parameter as a pointer followed by an int? For example:

  
  proc set_bytes(bytes: openarray[byte]) {.importc: "set_bytes".}
  
  let data: seq[byte] = @[1, 2, 3, 4]
  set_bytes(foo, data)
  Run

  Will this work going forward? (I could try it out myself, but that only means it works in Nim 1.2, not that it's expected/supported...)

---

• Araq (orginal) [2020-05-28T19:54:58+02:00] view original

  It's supposed to work, yes and should be documented in the manual.

---