3 ms·

Problem is, not only did we have decades of C code that unnecessarily assumed 8/16/32, this all-the-world-is-a-VAX view is now baked into newer languages. C is

Problem is, not only did we have decades of C code that unnecessarily assumed 8/16/32, this all-the-world-is-a-VAX view is now baked into newer languages. C is good for portability to this kind of machine. You can have a 36 bit int (for instance), CHAR_BIT is defined as 9 and so on. With a little bit of extra reasoning, you can make the code fit different machines sizes so that you use all the available bits.

pratyahava 1y ago
was that assumption in C code really unnecessary? i suppose it made many things much easier.
- kazinator 1y ago
  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 distinctions between "this type is guaranteed to be 32 bits" and "this type is guaranteed to wrap around to a negative value" or "if we shift this value 32 bits or more, we get zero so we are okay" and such. There are programmers who are not stupid like this, but those are the ones who will tend to reach for portable coding.
  - pratyahava 1y ago
    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.
    - kazinator 1y ago
      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 1y ago
        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 1y ago
        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 1y ago
        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.
0cf8612b2e1e 1y ago
Now a C++ proposal to define a byte as 8 bits https://isocpp.org/files/papers/P3477R1.html https://isocpp.org/files/papers/P3477R1.html
- kazinator 1y ago
  I worked in C for a DSP chip where the smallest data type was 16 bits. It was less than a decade ago.

pratyahava 1y ago

was that assumption in C code really unnecessary? i suppose it made many things much easier.

kazinator 1y ago
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 distinctions between "this type is guaranteed to be 32 bits" and "this type is guaranteed to wrap around to a negative value" or "if we shift this value 32 bits or more, we get zero so we are okay" and such. There are programmers who are not stupid like this, but those are the ones who will tend to reach for portable coding.
- pratyahava 1y ago
  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.
  - kazinator 1y ago
    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 1y ago
      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 1y ago
        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 1y ago
        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.

0cf8612b2e1e 1y ago

Now a C++ proposal to define a byte as 8 bits https://isocpp.org/files/papers/P3477R1.html https://isocpp.org/files/papers/P3477R1.html

kazinator 1y ago
I worked in C for a DSP chip where the smallest data type was 16 bits. It was less than a decade ago.