C strange struct behavior, what happens to size?

[westfw]

stay away from MIPS and some ARM chips, problem solved

One normally hopes that the compiler is smart enough to use byte/halfword instructions to access bytes and halfwords, so that you can substitute "be careful when you define the data structure" for "avoid cpus that can't do unaligned accesses."  As long as you have something like this (which will cover allmost all hardware register overlay applications):

Code: [Select]

struct {
   uint32_t longfield;
   uint16_t shortfield;
   uint8_t bytefield;
   uint8_t padding1;
}but you would have problems (if structures are packed) with accessing "shortfield" in this

Code: [Select]

struct {
   uint32_t longfield;
   uint8_t bytefield;
   uint16_t shortfield;
}(and yet, for Computer-Science-y applications, you don't want to force programmers to manually align the structures.)

[true]

That looks like eselect. O0

Or probably gcc-config -l

But probably without systemd either way, which is the best way 

[Jeroen3]

Play around with Offsetof. http://en.wikipedia.org/wiki/Offsetof to see how it packs stuff. (compilers can also warn you when they insert padding bytes  )

[legacy]

Or probably gcc-config -l

I am running gentoo/linux on {MIPS, ARM, X86} machines
I can switch the C compiler with "gcc-config"
followed by "source /etc/profile" to update the environment

[Bassman59]

But if you deal with an array of your struct there will be data fetching penalties. Processors pre-fetch data and miss-alignments will stall the pre-fetch queue. for for some structures you might not want to force it to 1 byte alignment.

If you use the structure to encapsulate hardware registers or I/O access, it's gotta be in a memory space marked as not-prefetchable (unless the hardware was designed with that capability in mind).

[Maxlor]

No, "long" is generally 32 bits, unless your compiler makes plain "int" 64 bits.

There were some Unix systems that used 64bit ints, but I'm not aware of any current one still doing that. Maybe there is an obscure one. But several different sizes are used for long on a 64bit machine. On most 64bit Unix-like systems, long is 64bits, whereas on 64bit Windows, long is 32bits.

MCU toolchains might use weird sizes (I've encountered the C compiler for a DSP where char was 16 bits...), but they generally follow the rule: char <= short <= int <= long <= long long. That could mean that all types are 16bits. There's only one thing to do: read the documentation when using a new toolchain or platform for the first time.

[legacy]

I've encountered the C compiler for a DSP where char was 16 bits

it happened to me, too, a lot of time ago, i think it was a Texas Instruments's DSP if i remember right

[miguelvp]

I've encountered the C compiler for a DSP where char was 16 bits

it happened to me, too, a lot of time ago, i think it was a Texas Instruments's DSP if i remember right

Kind of makes sense for UTF-16 Unicode, surprised it's not a default standard yet in this 21st century and 3rd millennium.

[westfw]

"char" is 16bits in Java (and 16bits/character for strings.)
They also apparently have "byte" to handle the 8bit case.

[vvanders]

Don't even get me started on Java that abomination of a language doesn't even have the concept of unsigned because it's apparently too hard to handle the overflow edge case. Or the fact that every literal is an integer so you can't have a byte literal, argh.

C# got so much of what Java was trying to do right, it's a shame it's so widely used and taught.

[SirNick]

char shouldn't be 16-bits, because if that's what you need, there's often wchar just for that purpose.  If we could turn back time, it would've been nice to have byte defined as an official type, and char could be whatever your platform prefers -- Unicode, ASCII, etc.

Although, if we're time-traveling, just dump int, short, long, etc., and start with int8_t, uint8_t, and so on, instead.  The size and endianness ambiguity of C is one of its biggest flaws WRT portability, in my not-so-expert opinion.  Having intrinsic and reliable ways to solve those two issues would've been really nice to have from day one.