Do you have a test case for this?
From what I'm seeing I think I'd prefer to fix tarnish to not pass in invalid strings to this. Assuming we know where that is happening.

The test case is a buggy max77818 driver that doesn't supply /sys/class/power_supply/max77818_battery/present to userspace. It isn't really something we need to handle nicely, but it would be great not to crash

The test case is a buggy max77818 driver that doesn't supply /sys/class/power_supply/max77818_battery/present to userspace. It isn't really something we need to handle nicely, but it would be great not to crash

That should still be caught and return a 0 with a warning logged out by strProperty, no? Or is it trying to read it and getting a non integer value?

I'm not seeing crashes logged for this, and I would expect to see quite a few, as well as reports that oxide isn't working for people.

That should still be caught and return a 0 with a warning logged out by strProperty, no? Or is it trying to read it and getting a non integer value?

It's trying to read it and getting a non-integer value, which then triggers the stoi() exception

I'm not seeing crashes logged for this, and I would expect to see quite a few, as well as reports that oxide isn't working for people.

I noticed this while re-writing the max77818 driver in preparation for the 6.3 kernel release and eventual upstreaming, so I don't think anyone would be reporting crashes

Okay, that makes sense now. I'll get this merged in a bit. Just trying to recover my reMarkable after bricking it when testing a change to the kernelctl package 😛