14:22 <kabel> anybody has solidrun lx2160 based board?

14:30 <apalos> i used to have one

14:32 <marex> i used to want one

14:35 <rfs613> tail = size % 4;

14:35 <rfs613> write(ifd, (char *)&zero, 4 - tail)

14:36 <rfs613> how many bytes can this copy?

14:36 <apalos> thats a trick question, it depends

14:37 <rfs613> enlighten me... ;-)

14:37 <rfs613> tail is an int, FWIW

14:38 <apalos> what's the second argument in write?

14:38 <apalos> bah let me remember promotion ruls,

14:41 <apalos> ah I lost the size % 4

14:41 <apalos> So at most 4?

14:41 <rfs613> that's what I would think.

14:41 <rfs613> but gcc-11 seems to think it could be as much as 5.

14:42 <rfs613> and it issues a warning that the source buffer ("zero") is not big enough.

14:42 <Tartarus> kabel: Jon used to be on IRC I think? And twitter, if he's not via email atm.

14:42 <apalos> what do you need the cast * for?

14:43 <apalos> write takes a void ptr

14:43 <rfs613> apalos: because in this case "zero" is defined as an int. (on arm32 platform, so it is 4 bytes).

14:43 <marex> rfs613: could that have to do with arm aligned LDR opcode ?

14:45 <rfs613> marex: hmm well the int zero, which is on the local stack frame, would be aligned on a multiple of 4 at least. So I don't see how alignment would cause it to read more than 4 bytes from the buffer.

14:46 <marex> rfs613: is size signed or unsigned ?

14:46 <apalos> rfs613: out of curiocity what's the tail type?

14:47 <rfs613> marex: size is an int

14:47 <rfs613> apalos: tail is also an int

14:48 <marex> rfs613: signed int ? :)

14:48 <marex> rfs613: could that have something to do with it ?

14:48 <apalos> rfs613: so everything is promoted to int, and even before that tail is 0...3

14:48 <apalos> I am confused :P

14:48 <rfs613> this code is from tools/imx8image.c. To "fix" the gcc warning, the type of "int zero" was changed to "unit64_t" in commit 16841a6a

14:48 <marex> apalos: I ran into similar weirdness with gcc 13 and sigrok, so I am also confused

14:50 <rfs613> I don't understand why gcc is complaining. And in terms of a fix, the same function has an uint8_t array called "zeros" which is memset to zero. So I would think they could just change the write() to use "zeros" instead of "zero" and that would take care of it as well.

14:52 <rfs613> also note this is built with $HOSTCC which in my case is x86_64, not arm...

14:53 <apalos> rfs613: whats the exact warning?

14:54 <rfs613> apalos: "warning: ‘write’ reading 5 bytes from a region of size 4"

14:54 <rfs613> gcc-9.2 does not produce it, but gcc-11 does.

14:58 <rfs613> it also reports: /usr/include/unistd.h:378:16: note: in a call to function ‘write’ declared with attribute ‘access (read_only, 2, 3)’

15:10 <kabel> Tartarus: jon who? :)

16:04 <Tartarus> kabel: https://twitter.com/linux4kix

16:05 <Tartarus> https://mastodon.online/@linux4kix as well, but not very active there either.

16:05 <Tartarus> But, uh, Jon @ SolidRun who deals with among other things that lx2160 desktop machine :)

17:03 <kabel> Tartarus: thx

18:55 <Tartarus> New topic, over here before I try and bring it up on the mailing list. Anyone have thoughts and perhaps more importantly skills/time to make a brief website for U-Boot? Simon got u-boot.org for us, and our readthedocs page automatically redirects to docs.u-boot.org, so we have that going now. An "easy" first step would be I think to just have the docs page also cover the main domain/CNAME at it or whatever

19:46 <f_> Tartarus: I could

19:49 <f_> I can make a website if y'all wish

19:55 <Tartarus> I should note that I don't have any ideas about hosting, so something low resource would be good too, in case it ends up being stuck on a personal cloud instance and hoping to stay in the free tier

19:56 <f_> oh I'm not the kind of person who JSifies webpages

19:56 <f_> HTML and CSS is enough for a website

19:57 <f_> *are enough

20:12 <Tartarus> Yeah, that sounds good to me :)

20:12 <Tartarus> Also means we don't have to worry about cookies if we never use any cookies

20:36 <f_> No need for cookies either, indeed :)