3 ms·

> Well, those chips are DSPs, which is kind of a different horse. This whole discussion has been about portable code. The point is that no matter what the hors

> Well, those chips are DSPs, which is kind of a different horse. This whole discussion has been about portable code. The point is that no matter what the horse is, you can still write code that works (and works efficiently). If you are writing a portable TCP/IP stack, then having a struct like you described doesn't help you one bit. It looks like you are setting things up so you can directly blat the bits into it (or avoid the copy and interpret some bits using this struct, whatever). If you do this, then you don't have portable code because of endianness. To make this code portable, you separate the in memory representation from the "on-wire" representation. The memory representation doesn't need compiler specific things like PACK_STRUCT_FIELD would expand to, it only needs types that are at least 16 or 32 bits wide. The code that fills in the struct needs to operate byte at a time and then fill in the struct members appropriately. Note that because byte in C isn't necessarily 8-bits wide, you have to be a little bit careful with the "byte-at-a-time" code, but it is very possible to write it so it works on any whacky machine that has a C compiler - including DSPs... they really aren't that special.

CamperBob2 10y ago
I think we have to decide whether we're talking about specialized and/or archaic technological artifacts or modern general-purpose processors. My interest is limited to the latter, all of which have C compilers that support 1, 2, 4, and 8-element wide integers composed of 8-bit bytes. Confining the notion of "portability" to these platforms is fine with me. I'll definitely have to yield the point with respect to older DSP chips; I've never written code for a 56K or a SHARC, and never will. Endianness is generally hidden with wrapper macros or functions, and I suppose you could do the same to pretend you're accessing integers of unsupported sizes. But you can rest assured that losing track of the sizes of the underlying types is going to bite you in the ass. If I can't use typedefs, I'll want to use some semantically-equivalent notational cues.
- TheNewAndy 10y ago
  You seem to think that it is difficult to write programs with this level of portability. It really isn't, you just program to the language spec, and everything else falls out. You don't need to come up with arbitrary rules about which processors are too specialized or archaic. The alternative you provide isn't obviously better than just writing portable code, but from what I can tell, you have never actually just tried the alternative. I can assure you that knowing that exact width of types is rarely useful when writing super portable code for platforms that are different enough that you are happy to decide that you wouldn't even bother coding for them. So I'm puzzled by why it suddenly becomes helpful when you decide you are only going to look at a subset of those platforms. Give an example of how it is going to bite me in the ass and then the discussion can be less emotional and actually based on facts.

CamperBob2 10y ago

I think we have to decide whether we're talking about specialized and/or archaic technological artifacts or modern general-purpose processors. My interest is limited to the latter, all of which have C compilers that support 1, 2, 4, and 8-element wide integers composed of 8-bit bytes. Confining the notion of "portability" to these platforms is fine with me. I'll definitely have to yield the point with respect to older DSP chips; I've never written code for a 56K or a SHARC, and never will. Endianness is generally hidden with wrapper macros or functions, and I suppose you could do the same to pretend you're accessing integers of unsupported sizes. But you can rest assured that losing track of the sizes of the underlying types is going to bite you in the ass. If I can't use typedefs, I'll want to use some semantically-equivalent notational cues.

TheNewAndy 10y ago
You seem to think that it is difficult to write programs with this level of portability. It really isn't, you just program to the language spec, and everything else falls out. You don't need to come up with arbitrary rules about which processors are too specialized or archaic. The alternative you provide isn't obviously better than just writing portable code, but from what I can tell, you have never actually just tried the alternative. I can assure you that knowing that exact width of types is rarely useful when writing super portable code for platforms that are different enough that you are happy to decide that you wouldn't even bother coding for them. So I'm puzzled by why it suddenly becomes helpful when you decide you are only going to look at a subset of those platforms. Give an example of how it is going to bite me in the ass and then the discussion can be less emotional and actually based on facts.