Memory alignment

[Tim Rentsch]

Re: Memory alignment

Keith Thompson <kst-u@mib.orgwrites :

Tim Rentsch <txr@alumnus.ca ltech.eduwrites :

lawrence.jones@ siemens.com writes:

[...]

No, the padding bytes are most definitely *not* yours to write to.
Although most implementations will let you get away with it, there are
implementations that do careful memory bounds checking and won't.

I'm sure someone with Larry Jones's credentials must be saying
something by this, but I'll be darned if I know what it is. Surely
padding bytes must be available for writing to, at least as unsigned
char, so functions with a qsort-like interface can be written.

>
The context was a discussion of the struct hack. For example, given:
>
struct h {
int i;
char arr[1];
};
struct h obj;
>
>[...]

Ahhh, okay. Accessing obj.arr[1] is always undefined behavior,
whether (struct h) has padding bytes or not.

[Why Tea]

Re: Memory alignment

Treating the structure as an array of unsigned char, and accessing

those bytes, including any padding bytes, is ok.
>

Thanks Keith. I wonder why it took 60 messages for someone
to make a statement as concise as this :)

Assuming that there are one or more padding bytes is non-portable
(and, in my opinion, unnecessary and poor style).

Sure.

[vippstar@gmail.com]

Re: Memory alignment

On Oct 10, 6:10 pm, Why Tea <ytl...@gmail.c omwrote:

[ Keith Thompson wrote this ]

Treating the structure as an array of unsigned char, and accessing
those bytes, including any padding bytes, is ok.

>
Thanks Keith. I wonder why it took 60 messages for someone
to make a statement as concise as this :)
>

Assuming that there are one or more padding bytes is non-portable
(and, in my opinion, unnecessary and poor style).

>
Sure.

Please don't snip attribution lines, ie the part that says "Keith
Thompson wrote:" or similar.
I restored it.

[Antoninus Twink]

Re: Memory alignment

On 10 Oct 2008 at 15:10, Why Tea wrote:

Thanks Keith. I wonder why it took 60 messages for someone to make a
statement as concise as this :)

Because rather than giving a simple answer to a simple question, the
"regulars" would rather turn every thread into a drama by pretending to
misunderstand what everyone else means, and going off into word games
and angels-on-the-head-of-a-pin arguments for post after post.

[Kenny McCormack]

Re: Memory alignment

In article <slrngev7v2.7k9 .nospam@nospam. invalid>,
Antoninus Twink <nospam@nospam. invalidwrote:

>On 10 Oct 2008 at 15:10, Why Tea wrote:

>Thanks Keith. I wonder why it took 60 messages for someone to make a
>statement as concise as this :)

>
>Because rather than giving a simple answer to a simple question, the
>"regulars" would rather turn every thread into a drama by pretending to
>misunderstan d what everyone else means, and going off into word games
>and angels-on-the-head-of-a-pin arguments for post after post.
>

Yes, and for most of them, it's the only thing resembling a life that
they will ever know.

Just once, I'd like a statement from the regs as to why they waste their
lives like this.

[David Thompson]

Re: Memory alignment

On Fri, 03 Oct 2008 13:43:30 -0700, Keith Thompson <kst-u@mib.org>
wrote:

Lowell Gilbert <lgusenet@be-well.ilk.orgwri tes:

Why Tea <ytlim1@gmail.c omwrites:

On Oct 3, 12:48 pm, danmat...@gmail .com wrote:

[...]

>Why would you want to declare a 1 char array to store 2 anyway?
>
Good question. This is found in some real embedded
code to make more efficient of the memory. As I understood
it, the last s[1] is just a placeholder as you can
allocate more memory when needed. For example:
>
my_struct = malloc(sizeof(m y_struct_t) + MY_PAYLOAD_STRI NG_SIZE);

or even more likely, something more like
my_struct = malloc(sizeof(m y_struct_t) + strlen(my->struct->s));

>

Not my->struct->s; that's a syntax error.

Guessing you (PP) meant my_struct->s, no. You need to compute the
length BEFORE allocating; and THEN set my_struct, and fill in
my_struct->whatever. Something much more like:
my_struct = malloc (sizeof(my_stru ct_t) + strlen(source_s tr) );
or the equivalent but clc-preferred
my_struct = malloc (sizeof *my_struct + strlen(source_s tr) );

+ 1. The length returned by strlen() doesn't include the terminating '\0'.

But if you use the C89-struct-hack version, with s[1], the sizeof the
struct already includes room for at least one byte, maybe more. I have
been known to write, for clarity(?!):
... malloc (sizeof(struct_ t) -1 +strlen(source_ str) +1 )
and sometimes to get stupid compilers to optimize even:
... malloc (sizeof(struct_ t) -1 +1 +strlen(source_ str) )

Or as already noted elsethread you use the offsetof variant:
... malloc (offsetof(struc t_t,s) +strlen(source_ str) +1 )

And that's not even considering the case where you don't need .s to be
nullterminated, typically because its length is stored elsewhere.

- formerly david.thompson1 || achar(64) || worldnet.att.ne t

[Richard]

Re: Memory alignment

vippstar@gmail. com writes:

On Oct 10, 6:10 pm, Why Tea <ytl...@gmail.c omwrote:

>[ Keith Thompson wrote this ]

Treating the structure as an array of unsigned char, and accessing
those bytes, including any padding bytes, is ok.

>>
>Thanks Keith. I wonder why it took 60 messages for someone
>to make a statement as concise as this :)
>>

Assuming that there are one or more padding bytes is non-portable
(and, in my opinion, unnecessary and poor style).

>>
>Sure.

>
>
Please don't snip attribution lines, ie the part that says "Keith
Thompson wrote:" or similar.
I restored it.

*chuckle*

Vippstar probably doesn't even realise the irony and humour in his
reply. Good to see not much has changed the past few weeks!