On Fri, 27 Apr 2018 16:48:57 -0700, Elliott Johnson said:
On 4/27/18 3:42 AM, Martin Simmons wrote:
I think that answer is "you are not supposed to do that" because there is no documentation for the slots of sensors_chip_name.
I'm not sure that I follow your point on the lack of "documentation for the slots of sensors_chip_name".
I followed the definitions in the c header file linked to below. Here is the header info:
I meant the documentation in https://github.com/groeck/lm-sensors/blob/master/lib/libsensors.3 (or man libsensors).
C header files often contain internal details that you are not supposed to use.
In the case of the cffi code, I use (with-foreign-object ...) to allocate the struct, so to test, I added a statement to my test function to initialize the path to an empty string before calling the parse function (which shouldn't touch the path slot):
(defun test-sensors-parse-chip-name (string) (with-foreign-object (name '(:struct sensors-chip-name)) (setf (foreign-slot-value name '(:struct sensors-chip-name) 'path) "") (unless (= 0 (cffi-sensors-parse-chip-name string name)) (error "Failed to parse: ~A" string)) (with-foreign-slots ((prefix bus address path) name (:struct sensors-chip-name)) (format t "~%Prefix: '~A'" prefix) (format t "~%Address: '~A'" address) (format t "~%Path: '~A'" path))))
When I execute this I get the following without error:
Yes, that will "work" but I still have doubts that this is the correct way to use sensors_parse_chip_name. I think it is supposed to used as the "match" argument to sensors_get_detected_chips.
It looks like the sensors_chip_name struct is used within the implementation of the library itself, where is does make use of the path slot.
__Martin