Prefer size_t over int where possible

[AtariDreams]

This avoids needless truncation, which takes up multiple more instructions on some architectures, especially older ones.

[enaess]

These fixes look mostly good. Though, some cases the refactoring changes the structure ... Comments inline to for @paulusmack to review.

[paulusmack]

I have mixed feelings about these changes. It's reasonable to use size_t for things that are the length of a structure or a string, but I don't think that the savings in code size will be significant either in space or time. There's also a lot of changes spread out across the source tree which could be better as separate commits.

[AtariDreams]

I have mixed feelings about these changes. It's reasonable to use size_t for things that are the length of a structure or a string, but I don't think that the savings in code size will be significant either in space or time. There's also a lot of changes spread out across the source tree which could be better as separate commits.

I think they would be best done at once, that's why, since they all have the same theme.

[Neustradamus]

@AtariDreams: It is not possible to separate?

[Neustradamus]

@AtariDreams: What is the solution?

[paulusmack]

I notice also that the signoff is a noreply.github.com address, which I don't consider adequate.

[Neustradamus]

@AtariDreams: Have you seen the @paulusmack comment?
What is the situation with your signoff?

[AtariDreams]

@Neustradamus Fixed!

[paulusmack]

In general it seems like there is a bunch of refactoring here plus gratuitous whitespace changes, in addition to the changes mentioned in the commit description (i.e. converting int to size_t). So, at the very least the commit description needs to be more comprehensive. If nothing else it should identify any potential bugs fixed here, though in fact I would prefer the bug fixes to be in separate commits.

I'm not convinced by the rationale that we need to do this to reduce the generated code size. As far as I can see it is only going to reduce the code size on 64-bit machines, not 32-bit machines, some of which might arguably be a bit short on memory. If you have a 64-bit processor you probably have a GB or more of memory, and saving at most a few hundred bytes of instruction memory is going to be in the noise.

[Neustradamus]

@AtariDreams: Have you seen @paulusmack comments started:

• Prefer size_t over int where possible #415 (review)

Note: The other PR has been merged :)

[Neustradamus]

@AtariDreams: Have you looked comments from @paulusmack?

[AtariDreams]

I'll take a look.

[Neustradamus]

@AtariDreams: Have you looked?
It will be good to have a solution before 2.5.1 release...

[paulusmack]

As far as I can see, there is no functional change here (or at least, none intended), so I am not going to wait for this.