Codechange: use standard int types #10733
Conversation
rubidium42
changed the title
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| static const uint8 ANIM_STATUS_NON_LOOPING = 0x00; ///< Animation is not looping. | ||
| static const uint8 ANIM_STATUS_LOOPING = 0x01; ///< Animation is looping. | ||
| static const uint8 ANIM_STATUS_NO_ANIMATION = 0xFF; ///< There is no animation. | ||
| static const uint8_t ANIM_STATUS_NON_LOOPING = 0x00; ///< Animation is not looping. |
Check notice
Code scanning / CodeQL
Unused static variable Note
rubidium42
force-pushed
the
big-diff
branch
2 times, most recently
from
10bdd7a
to
9dd1138
Compare
|
I think this would help for new developers to join in, as this makes this project more like other C++ projects. Similar to the efforts of converting to But, it is a total patch-killer, and as such, I think it is good to involve patchpacks; either by supplying seds or something, so they can go through a similar conversion. |
The probably should wait to just before branching 14, or at least just before the first beta. Regarding the sed, that's in the second paragraph of the automatic change commit of this PR. |
Well, what I more meant is: we should actual talk to patchpack owners; that kind of "involving". If for them this means it is a HUGE hassle to keep up-to-date with upstream, we shouldn't do this. |
|
I would like to see this if possible -- I had done global search & replaces to see what it looks like :-) However we can at least start to use the correct types piecemeal for future changes? |
rubidium42
force-pushed
the
big-diff
branch
3 times, most recently
from
3de22a4
to
792ff78
Compare
There was a problem hiding this comment.
Everyone I talked to signed off on this, as in:
@JGRennison indicated it doesn't bother him, and he will deal with it.
@PeterN, myself and OP would like to see this change.
Nobody else spoke up against it.
In general I think this is a good improvement, as everyone these days assume uint32_t. And as these days it works on all OSes, why not convert the rest to it so we can no longer use uint32 at all. This also makes things just slightly easier for new contributors, as it complies with modern expectations of a codebase.
And anyone else that runs a patchpack, there is enough information in this PR to do this on your own code too, saving you a lot of trouble. But can't deny, this will hurt a bit.
But so yeah, let's do this!
(you most likely have to check if this needs a rebase; just wanted to give the approval to make a point :D )
…32_t for i in `find src -type f|grep -v 3rdparty/fmt|grep -v 3rdparty/catch2|grep -v 3rdparty/opengl|grep -v stdafx.h`; do sed 's/uint16& /uint16 \&/g;s/int8\([ >*),;[]\)/int8_t\1/g;s/int16\([ >*),;[]\)/int16_t\1/g;s/int32\([ >*),;[]\)/int32_t\1/g;s/int64\([ >*),;[]\)/int64_t\1/g;s/ uint32(/ uint32_t(/g;s/_uint8_t/_uint8/;s/Uint8_t/Uint8/;s/ft_int64_t/ft_int64/g;s/uint64$/uint64_t/;s/WChar/char32_t/g;s/char32_t char32_t/char32_t WChar/' -i $i; done
Motivation / Problem
Using custom typedef for types that are standard types.
Mostly
(u)intXXthat can become(u)intXX_t, but alsoWCharbecomingchar32_t.Description
Automatic replacements; script in commit message.
Manual removal of the
typedefs from stdafx.h.Limitations
Breaks quite some patches.
Checklist for review
Some things are not automated, and forgotten often. This list is a reminder for the reviewers.