[kazinator]

> IMO whatever C can teach you, assembly can do better.

Other than, oh, things like getting the same code to produce exactly the same result on two different machines, where the sizes of the types being used by the code are different.

[UbrtrbNchDneRle]

I already addressed this. IMO the portability mantra is something I disagree over „C for everyone“. It’s an annoying obstacle, but not exactly fundamental or hard to learn on the job.

[kazinator]

I would guess that it's hard to learn that on the job, if the job consists of assembly language programming.

[mrmuagi]

Hmm, unless I am mistaken, does not using portable types stdint.h u?int(8|16|32)_t fix this?

[kazinator]

Using the same int<whatever>_t on all the targets may fix it in terms of correct behavior, but doesn't meet the definition of using different types on the different machines in the same overall logic, while getting the same result.

[mrmuagi]

I mean, you're right that this is a problem and it gives people the ability to shoot themselvesin the foot but bytes and byte order is apart of a C programmers framework for better or worse. I want to argue it gives you incredible control of the data at the lowest level and that's the tradeoff. If you write non portable code, it seems like you have to go out of your way not using standard portability types. If you define your own struct types I can see where this goes awray, but I think " __attribute__((__packed__))" eliminates alignment spaces for that case.

BUT, if you are coming from a networking/file perspective I can emphathize with you. Byte ordering is a pain for data serialization, even that has chance to cause issues and is no doubt a source of bug and pain.

[kazinator]

I mean, I can write code that has, say, this somewhere at the top:

  typedef unsigned int whatever_t;
  #define WHATEVER_MAX UINT_MAX

I can write the code such that I can edit whatever_t and WHATEVER_MAX to whatever values I want, and it still works, without changing any of the rest of the code.

This is not very highly abstract, but higher than assembly language.

If you want to teach this sort of hardware independence, asm is probably not the best teaching tool.