All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-c-programming <linux-c-programming@vger.kernel.org>
Subject: Re: memory_allocation
Date: Fri, 13 Aug 2004 15:01:53 +0200	[thread overview]
Message-ID: <20040813130153.GL16935@lug-owl.de> (raw)
In-Reply-To: <I2DXAF$7B97927BCA10A589B58FC0F34E16A58F@laposte.net>

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

On Fri, 2004-08-13 14:27:51 +0200, simon.guinot <simon.guinot@laposte.net>
wrote in message <I2DXAF$7B97927BCA10A589B58FC0F34E16A58F@laposte.net>:
> hello,
> 
> i have a problem with a structure memory allocation...
>  
> struct dns_answer {
>          unsigned short type;
>          unsigned short class;
>          unsigned int ttl;
>          unsigned short rdlength;
>          unsigned int addr_answer;
>          } dns_answ;
> 
> all this element are not adjacent in memory... i have two
> "free bytes" between rdlenght and addr_answer...
> since here, i have alway made my headers like this... and no
> problem...

You can add  "__attribute__ ((packed))" to the declaration of that
struct to force GCC to pack it. However, keep in mind that the gap does
serve a purpose! Accessing those parts at unaligned offsets may cause
quite some speed penalty on some CPUs. However, if it's a binary
structure (as it looks like), that's okay. (NB: Is your coding
endianess-save in that case?)

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2004-08-13 13:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-13 12:27 memory_allocation simon.guinot
2004-08-13 12:34 ` memory_allocation Henry Margies
2004-08-13 13:01 ` Jan-Benedict Glaw [this message]
     [not found] <fa.BkbRyK9fXhgijRwEDN4ejyJhMRQ@ifi.uio.no>
2007-04-17  5:08 ` Memory Allocation Robert Hancock
  -- strict thread matches above, loose matches on Subject: below --
2007-04-17  2:17 Brian D. McGrew
2007-04-17  7:06 ` Eric Dumazet
2007-04-18  4:47 ` David Schwartz
2003-09-14 18:44 1:1 M:N threading Breno
2003-09-14 19:11 ` Robert Love
2003-09-16 15:04   ` Memory allocation Breno
2001-02-27 16:55 Ivan Stepnikov
2001-02-27 17:51 ` Wayne Whitney
2001-02-27 17:55 ` Peter Samuelson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040813130153.GL16935@lug-owl.de \
    --to=jbglaw@lug-owl.de \
    --cc=linux-c-programming@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.