You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This IMO is a subtle bug which may be an off by one error somewhere in the generated output string buffer index.
In general if you use Bash to capture the output of the /proc/acpi/nuc_led to later process it like this:
nuc_led_output="$(cat /proc/acpi/nuc_led)"
Then you get a warning along the lines of:
Bash: warning: command substitution: ignored null byte in input
This is because you are adding the null byte ('\0') into the middle of the Bash string which internally is also a C string, so it ignores it.
This leads me to believe that the function that is creating the string buffer is either printing one character past the end of the actual buffer and overflowing it (causing the null character to be printed) or its being purposely injected/included in the output string. It would be better for the null byte not to be included in the output.
As a workaround, I have just been translating away the null byte:
@jernst thats not updated. I forked from them and maintain an updated downstream/merged with that one. This one still has the same issue unfortunately. Im going to try to send what I have upstream but I dont know if they will take it.
@jernst just noticed you were the one that worked on that repo. I just put up another commit that seems kinda related to these. I dont know if the kernel module isnt written correctly to support bufffered I/O on the /proc fs read or if these off by one issues are causing kernel panics on certain kernel versions. But it seems like on the 5.x kernels in 20.04/22.04, if you try to use buffered I/O with Python to read from the control file it causes a kernel panic which is weird but it resolves itself on the 6.0 OEM kernels in 22.04 (which should get merged into HWE kernel sometime in the summer). So im not sure if its the nuc wmi module or the kernel itself but its a weird edge case.
This IMO is a subtle bug which may be an off by one error somewhere in the generated output string buffer index.
In general if you use Bash to capture the output of the
/proc/acpi/nuc_led
to later process it like this:Then you get a warning along the lines of:
This is because you are adding the null byte ('\0') into the middle of the Bash string which internally is also a C string, so it ignores it.
This leads me to believe that the function that is creating the string buffer is either printing one character past the end of the actual buffer and overflowing it (causing the null character to be printed) or its being purposely injected/included in the output string. It would be better for the null byte not to be included in the output.
As a workaround, I have just been translating away the null byte:
The text was updated successfully, but these errors were encountered: