Author Topic: C strange struct behavior, what happens to size?  (Read 7198 times)

0 Members and 1 Guest are viewing this topic.

Online westfw

  • Super Contributor
  • ***
  • Posts: 3301
  • Country: us
Re: C strange struct behavior, what happens to size?
« Reply #25 on: September 21, 2014, 10:04:17 pm »
Quote
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.)
 

Offline true

  • Frequent Contributor
  • **
  • Posts: 298
  • Country: us
  • INTERNET
Re: C strange struct behavior, what happens to size?
« Reply #26 on: September 22, 2014, 05:01:27 am »
That looks like eselect. O0

Or probably gcc-config -l

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

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 3588
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: C strange struct behavior, what happens to size?
« Reply #27 on: September 22, 2014, 02:09:57 pm »
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  ;))
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: C strange struct behavior, what happens to size?
« Reply #28 on: September 22, 2014, 02:30:21 pm »
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
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1581
  • Country: us
  • Yes, I do this for a living
Re: C strange struct behavior, what happens to size?
« Reply #29 on: September 22, 2014, 05:19:23 pm »
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).
 

Offline Maxlor

  • Frequent Contributor
  • **
  • Posts: 565
  • Country: ch
Re: C strange struct behavior, what happens to size?
« Reply #30 on: September 22, 2014, 09:20:57 pm »
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.
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: C strange struct behavior, what happens to size?
« Reply #31 on: September 22, 2014, 10:39:50 pm »
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
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: C strange struct behavior, what happens to size?
« Reply #32 on: September 22, 2014, 10:50:26 pm »
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.
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 3301
  • Country: us
Re: C strange struct behavior, what happens to size?
« Reply #33 on: September 22, 2014, 11:33:29 pm »
"char" is 16bits in Java (and 16bits/character for strings.)
They also apparently have "byte" to handle the 8bit case.
 

Offline vvanders

  • Regular Contributor
  • *
  • Posts: 124
Re: C strange struct behavior, what happens to size?
« Reply #34 on: September 23, 2014, 12:59:48 am »
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.
 

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: C strange struct behavior, what happens to size?
« Reply #35 on: September 23, 2014, 08:32:29 pm »
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf