yep, i remember when i tried coding for some atmega, i was wondering "how big ar...

kazinator · 2025-08-07T00:48:16 1754527696

Would you want the main function to be:

  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"?

zozbot234 · 2025-08-07T05:52:41 1754545961

You'd define architecture-specific typedefs to deal with these cases in a portable way. The C standard already has types like int_fast8_t that are similar in principle.

kazinator · 2025-08-07T07:23:23 1754551403

See, why would you need an "architecture specific typedef" in order to represent the day of the month, or the number of arguments in main "in a portable way". int does it in a portable way already.

It's just muddled thinking.

zozbot234 · 2025-08-07T08:31:55 1754555515

int is architecture specific too, and it's been "muddled" plenty due to backward compatibility concerns. Using typedefs throughout would be a cleaner choice if we were starting from scratch.