[Toybox] [PATCH] devmem: Fix 8 byte wide writes

[enh]

the attached patch gives us your nice "%lx>%d bytes" error for all cases.

On Mon, Oct 9, 2023 at 9:42 PM Rob Landley <rob at landley.net> wrote:
>
> On 10/9/23 17:04, enh wrote:
> > On Mon, Oct 9, 2023 at 2:45 PM Rob Landley <rob at landley.net> wrote:
> >>
> >> On 10/9/23 10:26, enh wrote:
> >> >> Let me know how commit 5f153b56214f works? I don't have a test environment
> >> >> for this, but it seems to produce the errors right on 32 and 64 bit at
> >> >> least...
> >> >
> >> > it's a bit early in the morning for me, but doesn't the change from
> >> > `unsigned long long` to `unsigned long` mean that by the time you test
> >> > the result it can't be too large because you've already truncated?
> >>
> >> The theory is that by switching strtoull() to strtoul() we get ERANGE when it's
> >> truncated.
> >
> > ah, yeah, i see. (a shame though, because i much prefer the "%lx>%d
> > bytes" error message. but i'm unlikely to ever run a 32-bit toybox
> > binary ever again, so my opinion isn't worth much :-) )
>
> You still get that for 1 and 2 bytes, it's just the max size that never makes it
> to the later test if it can't parse from ascii into the long.
>
> This was already the case for 8 bytes on 64 bit. It can't say doesn't fit in 8
> bytes, so it says whatever the strerror() for ERANGE is...
>
> libc/bionic/strerror.cpp:    [ERANGE] = "Math result not representable",
>
> That.
>
> Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-devmem-unify-error-reporting.patch
Type: text/x-patch
Size: 1730 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20231010/9d7defd7/attachment.bin>