#607 linux:tcsetattr fails - ffi problem

lisp error
closed-fixed
clisp (525)
5
2011-09-14
2011-09-10
Brad Parker
No

I'm using the stock clisp on ubuntu 9.1 (which is admitted, old).
The linux:tcsettattr call fails with an ffi problem.

sorry if this has been fixed.

Welcome to GNU CLISP 2.44.1 (2008-02-23) <http://clisp.cons.org/>

(let* ((descriptor (linux:open "/dev/ttyS0" ;;(device port)
(logior linux:O_RDWR linux:O_NDELAY)
(logior linux:S_IRUSR linux:S_IWUSR)))
(attributes (get-attributes descriptor)))
(linux:tcsetattr descriptor linux:TCSANOW (linux:tcgetattr descriptor)))

*** - FFI::FOREIGN-CALL-OUT: Illegal foreign data type "tcflag_t"

Discussion

  • Sam Steingold

    Sam Steingold - 2011-09-13

    I do not have the "get-attributes" function.
    here is what I see with the current hg head:

    [1]> (linux:open "/dev/ttyS0" ;;(device port)
    (logior linux:O_RDWR linux:O_NDELAY)
    (logior linux:S_IRUSR linux:S_IWUSR)))
    4
    [2]> (linux:tcgetattr 4)
    -1 ;
    #S(LINUX:termios :C_IFLAG 0 :C_OFLAG 0 :C_CFLAG 0 :C_LFLAG 0 :C_LINE 0
    :C_CC #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0)
    :C_ISPEED 0 :C_OSPEED 0)
    [3]>

    is this reasonable?

     
  • Brad Parker

    Brad Parker - 2011-09-14

    it's the tcsetattr that is failing;

    can you try this:

    (linux:tcsetattr descriptor linux:TCSANOW (linux:tcgetattr descriptor))

    That is what is failing - it returns "*** - FFI::FOREIGN-CALL-OUT: Illegal foreign data type "tcflag_t""

     
  • Sam Steingold

    Sam Steingold - 2011-09-14

    [1]> (linux:open "/dev/ttyS0" ;;(device port)
    (logior linux:O_RDWR linux:O_NDELAY)
    (logior linux:S_IRUSR linux:S_IWUSR)))
    4
    [2]> (linux:tcgetattr 4)
    -1 ;
    #S(LINUX:termios :C_IFLAG 0 :C_OFLAG 0 :C_CFLAG 0 :C_LFLAG 0 :C_LINE 0
    :C_CC #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0)
    :C_ISPEED 0 :C_OSPEED 0)
    [3]> (linux:tcsetattr 4 linux:TCSANOW -1)

    *** - FFI::FOREIGN-CALL-OUT: -1 cannot be converted to the foreign type
    #(FFI:C-STRUCT LINUX:termios NIL
    #(LINUX::c_iflag LINUX::c_oflag LINUX::c_cflag LINUX::c_lflag
    LINUX::c_line LINUX::c_cc LINUX::c_ispeed LINUX::c_ospeed)
    #<COMPILED-FUNCTION LINUX:make-termios> #1="tcflag_t" #1# #1# #1#
    #2="cc_t" #(FFI:C-ARRAY #2# 32) #3="speed_t" #3#)

    Break 1 [4]>
    [9]> (linux:tcsetattr 4 linux:TCSANOW (nth-value 1 (linux:tcgetattr 4)))
    -1

    i.e., I do not get the 'illegal foreign data type" error.

     
  • Brad Parker

    Brad Parker - 2011-09-14

    Right. I see that. But you're not doing what I did.

    linux:txgetattr returns a structure.

    linix:tcsetattr takes a structure.

    what you did, namely:

    Break 1 [4]>
    [9]> (linux:tcsetattr 4 linux:TCSANOW (nth-value 1 (linux:tcgetattr 4)))
    -1

    does not send a structure to linux:tcsetattr. So, it failed and returned an error (-1).

    I want you to try this:

    (linux:tcsetattr 4 linux:TCSANOW (linux:tcgetattr 4))

    Which will send the entire output of tcgetattr to tcsetattr. That is what I did and that is what failed.

    thanks

     
  • Brad Parker

    Brad Parker - 2011-09-14

    Wait. I am wrong. my appologies.

    linux:tcgetattr returns multiple values. What you did is correct.

    And it does not seem to fail in the same way running from the top of the tree.

    ok, thanks - I think that answers my question.

     
  • Sam Steingold

    Sam Steingold - 2011-09-14
    • assigned_to: haible --> sds
    • status: open --> closed-fixed
     
  • Sam Steingold

    Sam Steingold - 2011-09-14

    thank you for your bug report.
    the bug has been fixed in the source tree (mercurial/hg).
    you can either wait for the next release (recommended)
    or check out the current mercurial tree (see http://clisp.org\)
    and build CLISP from the sources (be advised that between
    releases the source tree is very unstable and may not even build
    on your platform).

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks