Incorrect decoding of LSTAT message in python as PD

[rm5248]

Describe the bug
When a CP sends an LSTAT message to a python PD, the python code will have a very long report entry. When a CP sends a PD an LSTAT message, there is no data in this message, but libosdp is assuming that there is. This results in reading junk data.

Expected behavior
The PD message should not have a report entry

Observed behavior
A description of what happened.

A Comprehensive Log file

OSDP: PD-0: 2025-12-22T22:16:52Z   osdp_pd.c:732  [DEBUG] CMD: LSTAT(64) REPLY: LSTATR(48)
PD: Received command: {'command': 9, 'type': 2, 'report': b'\xcc\x89$\xac2\x7f\x00\x .... (data continues on here for many many bytes)

[sidcha]

When the CP sends a LSTAT (and similar status request commands), the LibOSDP PD parses this command presents it as-is to the PD app in the command call back. The app is expected to fill in the event structure (report and nr_entries fields) with the local status report (by reading the GPIOs or whatever) and return 0. Then the PD responds to the CP.

In python, this would translate to something like this:

def cmd_handler(command):
     cmd = {
        'command': Command.Status,
        'type': StatusReportType.Input,
        'report': bytes([ 0, 1, 0, 1, 0, 1, 0, 1 ])
    }
    return 0, cmd

But there is a quirk with the way the python library is exposed -- it sets an internal command callback handler and exposes a higher level API to the PD app for convenience. You are free to overwrite that with your own handler (using pd.set_command_handler(cmd_handler)) but then you must handle all event management yourself.

Give it a try and let me know if it works. I am open for discussions alternate ways to achieve this effect.

[rm5248]

When the CP sends a LSTAT (and similar status request commands), the LibOSDP PD parses this command presents it as-is to the PD app in the command call back. The app is expected to fill in the event structure (report and nr_entries fields) with the local status report (by reading the GPIOs or whatever) and return 0. Then the PD responds to the CP.

Yes, but there's a problem with presenting the command as-is: because the message from the CP has no data according to the spec, the message gets passed to python with uninitialized memory. The python code converts it here:

libosdp/python/osdp_sys/data.c

Line 514 in 5acf8fd

if (pyosdp_dict_add_bytes(obj, "report", event->status.report, event->status.nr_entries))

Because the conversion code doesn't know that there shouldn't be data there, it happily goes along and converts the struct, making a giant array in the process. This occasionally leads to a segfault, depending on how long it thinks the array is.