Earlier quoted context omitted.
In my experience, highly portable C is cleaner and easier to understand and maintain than C which riddles abstract logic with dependencies on the specific parameters of the abstract machine. Sometimes the latter is a win, but not if that is your default modus operandi. Another issue is that machine-specific code that assumes compiler and machine characteristics often has outright undefined behavior, not making distin…
yep, i remember when i tried coding for some atmega, i was wondering "how big are int and uint?" and wanted the types names to always include the size like uint8. but also there is char type, which should become char8 which looks even more crazy.
int32_t main(int32_t argc, char **argv)?
How about struct tm? struct tm {$
int32_t tm_sec; /* Seconds (0-60) */$
int32_t tm_min; /* Minutes (0-59) */$
int32_t tm_hour; /* Hours (0-23) */$
int32_t tm_mday; /* Day of the month (1-31) */$
int32_t tm_mon; /* Month (0-11) */$
int32_t tm_year; /* Year - 1900 */$
int32_t tm_wday; /* Day of the week (0-6, Sunday = 0) */$
int32_t tm_yday; /* Day in the year (0-365, 1 Jan = 0) */$
int32_t tm_isdst; /* Daylight saving time */$
};
What for? Or do we "shrink wrap" every field to the smallest type? "uint8_t tm_hour"?