Okay, this is a difficult one to explain. I've tried it twice. I've failed twice. Here goes anyway! It all boils down to the fact that information is only bytes which we interpret to suit our needs. The hex number #60 (0x60 for us C freaks) can be interpreted in a number of ways: in 6502 machine language, it's interpreted as RTS.
All this business with struct this and enum that is getting annoying, right? Why should you have to stick struct or enum before the name of your data type? Well, one reason is that you can easily have both a struct x and an enum x without C getting confused. But it's still annoying. This is why you can name your own data types using the typedef keyword:
The struct ceo_member we discussed previously takes quite a lot of memory. For example, why do we allocate a ten byte string for the machine type, since we've only got three different machines? You'd argue that we could use a single byte to store this information. You'd be right! We can and should do this. One way to do it is by making machine a char. Then, different values would ‘mean’ different machines. There's a nicer way: an enumerated data type, known as an enum in C:
Assume that Laurent, for some elusive reason, needs to keep a record of all CEO members using a C program. He needs to keep diverse information on each member like their name, their snail-mail and e-mail addresses, the date when they first subscribed and the type of machine they have (Oric-1, Atmos or Telestrat). People with previous Pascal experience will be smiling, BASIC users will be curious, and I hope there aren't any COBOL users around.
By this point you should be wondering about the weird, seemingly inconsistent use of arrays (and strings) in C. It's puzzling until you learn one little secret. This is where this secret is unveiled.
