this post was submitted on 26 Jul 2026
29 points (70.4% liked)
Technology
86679 readers
2486 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I come from a background of porting code between architectures, like 16 to 32 bit. The int type in C was (is) ambiguous in that case, 16 bit signed int on the 16 bit system, 32 bits on the 32 bit system. First thing I had to do to make the 500,000 LOC package start to run properly when ported from 16 bits to 32 bits was find and replace all " int "with " int16 ", "(int)" with "(int16)" etc. It was only going wrong "quite rarely" - but "quite rarely" doesn't cut it, they ALL needed to behave predictably the same as they did before the move. I believe that effort took 3 solid work days, 24 hours of my life, because "int" was "good enough" for the previous team.
Er… okay, yes. That would be quite the annoyance, but thats a bit of an edge case in this instance. I’d also wager that current implementations of IDEs would allow you to intelligently replace int with Int16/Int32/Int64 depending on the context before migration. I believe Visual Studio proper has that as an option in its code analysis and cleanup tool. You can also do the same for var => string typing if I remember correctly.