Structure size

[BobR]

struct mystruct {
int var1, var2, var3;
char data[1024 - offsetof(data)];

That's "offsetof( mystruct, data )", of course (as you've
already corrected).

I don't think you can use offsetof on an incomplete type.

As poor Bruce found out.

If you can't find a sane way to do it, think outside the box.

struct dummy{
int var1, var2, var3;
char data[1];
};

struct mystruct{
int var1, var2, var3;
char data[ 1024 - offsetof( dummy, data ) ];
};

// cout<<"sizeof dummy="<<sizeof(dummy)<<std::endl;
// cout<<"sizeof mystruct="<<sizeof(mystruct)<<std::endl;
// sizeof dummy=16
// sizeof mystruct=1024


We'd have to assume (or prey) that the compiler would construct the two
structs the same (up to 'data').

No, it wasn't my bath-water I drank!
<G>

 

[Bo Persson]

BobR wrote:
:: On Jul 22, 9:03 pm, "Victor Bazarov" <[email protected]>
:: wrote:
::
:::: struct mystruct {
:::: int var1, var2, var3;
:::: char data[1024 - offsetof(data)];
::
::: That's "offsetof( mystruct, data )", of course (as you've
::: already corrected).
::
:::: };
:::: Should that alleviate any trouble with possible padding?
::
::: I don't think you can use offsetof on an incomplete type.
::
:: As poor Bruce found out.
::
:: If you can't find a sane way to do it, think outside the box.
::
:: struct dummy{
:: int var1, var2, var3;
:: char data[1];
:: };
::
:: struct mystruct{
:: int var1, var2, var3;
:: char data[ 1024 - offsetof( dummy, data ) ];
:: };
::
:: // cout<<"sizeof dummy="<<sizeof(dummy)<<std::endl;
:: // cout<<"sizeof mystruct="<<sizeof(mystruct)<<std::endl;
:: // sizeof dummy=16
:: // sizeof mystruct=1024
::
::
:: We'd have to assume (or prey) that the compiler would construct
:: the two structs the same (up to 'data').
::

Unfortunately, I don't think we can be sure about that (except in
practice.

An architecture odd enough to require padding between integers, or
between an integer and a char, could of course have different padding
for an odd number of characters (char[1]) and an even number of
characters (assuming, again, that's what we get .

I think [1024 - 3 * sizeof(int)] would work just as well. Otherwise we
should also start to think about the size of a byte. Are there 8 bits
in a char?!



Bo Persson

 

[BobR]

BobR wrote:
::
::: I don't think you can use offsetof on an incomplete type.
::
:: As poor Bruce found out.
:: If you can't find a sane way to do it, think outside the box.
:: struct dummy{
:: int var1, var2, var3;
:: char data[1];
:: };
:: struct mystruct{
:: int var1, var2, var3;
:: char data[ 1024 - offsetof( dummy, data ) ];
:: };
:: // cout<<"sizeof dummy="<<sizeof(dummy)<<std::endl;
:: // cout<<"sizeof mystruct="<<sizeof(mystruct)<<std::endl;
:: // sizeof dummy=16
:: // sizeof mystruct=1024
:: We'd have to assume (or prey) that the compiler would construct
:: the two structs the same (up to 'data').
::

Unfortunately, I don't think we can be sure about that (except in
practice.

An architecture odd enough to require padding between integers, or
between an integer and a char, could of course have different padding
for an odd number of characters (char[1]) and an even number of
characters (assuming, again, that's what we get .

I think [1024 - 3 * sizeof(int)] would work just as well. Otherwise we
should also start to think about the size of a byte. Are there 8 bits
in a char?!

No, there are 8 bits in a byte (Webster's <G>). If the byte is RAM, it's 9
bits (the parity bit :-}) in many/most machines in use (Intel,AMD (did Apple
completely drop Motorola?)). [ loosely speaking. ]
That's one thing I (slightly) miss about Assembler, being able to lay out
things exactly where I want them. What I don't miss is the memory management
(real, flat, protected (IA32)). So 'char' don't look so bad from where I
sit. I let the compiler worry about it's size in 9999 of 10000 cases.

The OP should be using Assembler for what (s)he wants to do, IMHO.
Or, 'std::vector<unsigned char> MyStruct(1024)', and some *heavy* casting
(dang endians!). <G>

 

[Richard Heathfield]

BobR said:

No, there are 8 bits in a byte (Webster's <G>).

Webster's is not normative. In both C and, I am given to understand,
C++, there are CHAR_BIT bits in a byte, where CHAR_BIT is at least 8. A
byte is exactly big enough to store one char.

 

[BobR]

BobR said:

[ I should have 'double-grin'-ed that line. ]

Webster's is not normative. In both C and, I am given to understand,
C++, there are CHAR_BIT bits in a byte, where CHAR_BIT is at least 8.
A byte is exactly big enough to store one char.

Yep. In C || C++, I'd go by the CHAR_BIT.
"...., there are CHAR_BIT bits in a 'char' ", would be more proper
terminology, I think.

 

[Jerry Coffin]

[ ... ]

Yep. In C || C++, I'd go by the CHAR_BIT.
"...., there are CHAR_BIT bits in a 'char' ", would be more proper
terminology, I think.

Not really -- as the terms are used in the standards, 'char' is a type
whereas 'byte' is an amount of storage. As it happens, the standards go
on to require that a byte is always exactly enough storage to hold an
object of type char (and, due to other requirements, signed char or
unsigned char).

Nonetheless, the type char is more or less distinct from the amount of
storage it occupies -- in particular, there are a few requirements on
the char type that go beyond the fact that it has to fit in one byte of
storage.

 

[James Kanze]

No, there are 8 bits in a byte (Webster's <G>).

Then Webster's wrong. The original use was for 6 bits, on a
PDP-10, it was programmable (7 was conventionally used, but
implementations of C used 9), on a CDC mainframe, 10. Of
course, a byte was 8 bits on an IBM 360, and later on the
PDP-11, and those were very influential machines.

That's why line protocols are defined in terms of octets, and
not bytes.

If the byte is RAM, it's 9
bits (the parity bit :-}) in many/most machines in use (Intel,AMD (did Apple
completely drop Motorola?)). [ loosely speaking. ]

At one time, at least, a lot of machine memory used
auto-corrector codes (not parity). Something like 37 physical
bits for 32 accessible to the program. (Back in the good old
days, of course, memory was core. You could toggle your program
in on the front panel of one machine, turn the machine off, take
the memory board out, and insert it into another machine, and
still have your program. Times have changed, however, and I
don't quite see myself toggling in the machine instructions for
the latest Linux on a front panel. Even if the machine had a
front panel.)

 

[LR]

Then Webster's wrong. The original use was for 6 bits, on a
PDP-10, it was programmable (7 was conventionally used, but
implementations of C used 9), on a CDC mainframe, 10.

Did you mean 12? Or maybe you meant 10 characters per CPU word? AFAIR,
on CDC 6600s, Cyber 70s and 700s and and even the 800s in 700
compatibility mode (which I think they had) bytes were 12 bits,
essentially the size of a PP word, and characters were, well, thats a
can of worms, but the 63 and 64 character sets had 6 bit characters and
then I think there were variations on 8 and maybe 9 bit characters with
various packings and also 12 bit characters of two or maybe three kinds,
escaped 6 bit and 8 bits packed in 12. Of course I/O was another set of
problems. And I don't recall at all how the APL character set was
stored, but I think there may have been a few tricks.

Talk about fun! How do we read that file again?

LR

 

[James Kanze]

Did you mean 12?

Maybe. It's been a very, very long time. I seem to remember
something about 6 10 bit bytes in a 60 bit word. But that could
be completely wrong.

My point was only that byte size has always varied.

 

[Jerry Coffin]

[ 'byte' on Control Data mainframes ... ]

Maybe. It's been a very, very long time. I seem to remember
something about 6 10 bit bytes in a 60 bit word. But that could
be completely wrong.

It's backwards: the most common setup was 10 6-bit bytes in a 60-bit
word.

My point was only that byte size has always varied.

....and that is certainly valid.

 

[LR]

[ 'byte' on Control Data mainframes ... ]

Maybe. It's been a very, very long time. I seem to remember
something about 6 10 bit bytes in a 60 bit word. But that could
be completely wrong.

It's backwards: the most common setup was 10 6-bit bytes in a 60-bit
word.

No. It was six bit characters. The bytes were 12 bits, the size of a PP
word.

...and that is certainly valid.

Have to agree with that.

LR

 

[Jerry Coffin]

[ ... ]

No. It was six bit characters. The bytes were 12 bits, the size of a PP
word.

Sorry -- I was using 'byte' as the C and C++ standards do -- to mean the
amount of storage needed for a character. For better or worse, people
have enough different meanings for "byte" that it's hard to be sure
what's meant without specifying...

 

[LR]

[ ... ]

No. It was six bit characters. The bytes were 12 bits, the size of a PP
word.

Sorry -- I was using 'byte' as the C and C++ standards do -- to mean the
amount of storage needed for a character. For better or worse, people
have enough different meanings for "byte" that it's hard to be sure
what's meant without specifying...

I understand, but the C++ standard says "Every byte has a unique
address." and that's a little difficult to apply to a machine (since we
included the 6600) whose CPU addresses 60 bit words. OTOH the PPs
could address 12 bit words.

Of course, we'd have to be careful about dealing with the character
instructions that were added to, I think, the Cyber 70s.

LR

 

[James Kanze]

[ 'byte' on Control Data mainframes ... ]

Maybe. It's been a very, very long time. I seem to remember
something about 6 10 bit bytes in a 60 bit word. But that could
be completely wrong.

It's backwards: the most common setup was 10 6-bit bytes in a 60-bit
word.

But of course, an implementation of C couldn't use this
arrangement. (I was just guessing what C would look like on the
machine. The only program I actually ever wrote on it was in
Fortran.)

At any rate, as I said, it was a long time ago, so memory could
be playing any sort of tricks on me. And it didn't seem worth
the bother of looking it up, since I rather doubt I'll have to
write code for that machine anytime in the near future.

 

[Jerry Coffin]

[ ... ]

I understand, but the C++ standard says "Every byte has a unique
address." and that's a little difficult to apply to a machine (since we
included the 6600) whose CPU addresses 60 bit words. OTOH the PPs
could address 12 bit words.

C and C++ both require a minimum of 8 bits for characters in any case.

As far as addressing goes, you'd (probably) do about like most C
compilers for the Cray did: a pointer to the word along with a small
integer specifying a character in the word. It's been a long time, but
if memory serves that's roughly how a pointer to char in Pascal 6000 was
implemented.

 

[Jerry Coffin]

[ CDC mainframes ... ]

At any rate, as I said, it was a long time ago, so memory could
be playing any sort of tricks on me. And it didn't seem worth
the bother of looking it up, since I rather doubt I'll have to
write code for that machine anytime in the near future.

Should you get an irresistible urge to do so, Google for "dtcyber", and
you'll find there's a fairly accurate emulator for it that runs under
Windows...

 

[LR]

[ CDC mainframes ... ]

At any rate, as I said, it was a long time ago, so memory could
be playing any sort of tricks on me. And it didn't seem worth
the bother of looking it up, since I rather doubt I'll have to
write code for that machine anytime in the near future.

Should you get an irresistible urge to do so, Google for "dtcyber", and
you'll find there's a fairly accurate emulator for it that runs under
Windows...

Is there a COMPASS ng for any questions that come up?

LR

 

[Jerry Coffin]

[ ... ]

Is there a COMPASS ng for any questions that come up?

None of which I'm aware...nor (TTBOMK) are there any NGs for Scope, NOS,
NOS/VE, etc.