Alright, this is what I got working for the posix stuff: 
    
    
    {.passL: "-lutil".}
    
    var SIGWINCH* {.importc, header: "<signal.h>".}: cint
    var TIOCGWINSZ* {.importc, header: "<termios.h>".}: cuint
    var TIOCSWINSZ* {.importc, header: "<termios.h>".}: cuint
    
    proc openpty (amaster, aslave : ptr int, mustBeNil : pointer, termp, winp : 
ptr Termios) : cint {.importc, noDecl, header: "<pty.h>".}
    proc forkpty (amaster: ptr int, mustBeNil : pointer, termp, winp : ptr 
Termios) : cint {.importc, noDecl, header: "<pty.h>".}
    

I need to the put what will make **{.passL: "-lutil".}** happen in the importc 
pragmas for openpty and forkpty, but I'm not sure how to do that. dynlib did 
not do it.

With the above I was able to port the remaining C functions to Nim.

As far as **SigVal** not having **sival_int** an only having **sival_ptr**, 
here was my workaround:
    
    
    # for inserting:
    var si_value:SigVal
    si_value.sival_ptr = cast[pointer](myvar)
    let rc = pid.sigqueue (SIGUSR2, si_value)
    
    # for extracting:
    proc handler (signal:cint, si: var SigInfo, context:pointer) {.noconv.} =
        let myvar = cast[mytype](si.si_value.sival_ptr)
    

Where **mytype** objects are pointer sized or smaller, in my case I'm using an 
enum type. I guess because of that, I don't really see the need to support 
sival_int directly in Nim.

Should something like this be included in the PR?

Here is what is says currently:
    
    
    SigVal* {.importc: "union sigval",
                 header: "<signal.h>", final, pure.} = object ## struct sigval
        sival_ptr*: pointer ## pointer signal value;
                            ## integer signal value not defined!
    

On a different note, why were these renamed?

  * **cfmakeraw** to _cfMakeRaw_
  * **tcsetattr** to _tcSetAttr_
  * **tcgetattr** to _tcGetAttr_



Due to case insensitivity they worked without the camelcase. The reason I 
initially thought they were missing was I could not find the in the 
documentation.

readlink was not renamed to readLink, setgid to setGid, etc, so I don't really 
see a point in renaming the aforementioned.

So, when I do a PR, I'll need to add the proper docstrings, for the new ones 
above as well. 

Reply via email to