public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Grant Edwards" <grante@visi.com>
To: "Trenton D. Adams" <tadams@theone.dnsalias.com>
Cc: "'Jonathan Larmour'" <jlarmour@redhat.com>,
	"'Andrew Lunn'" <andrew.lunn@ascom.ch>,
	"'eCos discussion'" <ecos-discuss@sources.redhat.com>
Subject: [ECOS] Re: Network programming for eCos under linux
Date: Wed, 08 Aug 2001 08:57:00 -0000	[thread overview]
Message-ID: <20010808155704.20E397A926@visi.com> (raw)
In-Reply-To: <003001c12020$c6da1d70$090110ac@TRENT>

Trenton D. Adams writes:

>   > <soapbox>
>   > 
>   > I've claimed for many years that C, as a systems language,
>   > should provide a way for the user to specify data layout in
>   > memory when it is require for meeting external requirements
>   > such as memory mapped hardware, comm protocols, etc.  This
>   > would allow the user to control data layout in a static,
>   > declaritive approach, similar to the way C deals with data
>   > types and scoping: all three would be could declared at
>   > compile-time.
>   > 
>   > The C language mavens reply that C _could_ do something like
>   > that, but they prefer to leave it up to the user to shovel
>   > individual bytes around to get them arranged as desired. (That
>   > way it's much more error prone and uses up more CPU cycles!)
>   > They seem to prefer an imperitive approach, where you layout
>   > data at run-time rather than at compile time, even though
>   > everything else about data objects (type, scope) is defined at
>   > compile time.
>   > 
>   > I don't understand their reasoning, but there's no way I'm ever
>   > going to convince them to change things now. :)
>   > 
>   > </soapbox>
>   >  
> 
> Well apparently Microsoft's compiler doesn't follow the standard then!
> Oh, that's a big surprise!!!! ;) LMAO.  Anyhow, it allows you to specify
> alignment for compile time.  I would have to say that in this case, I
> agree with Microsoft not following the standard! :)  
>

Gcc does let you partially specify alignment/packing: AFAIK, qthere's no way 
to prevent it from padding the end of the struct.  But, it won't
generate guaranteed valid instruction sequences when you access the fields.  
If you could at least prevent the padding, you could use fields
as targets for memcpy() operations, but the padding prevents that from
being a usable option. 

[Apologies for message formatting problems. My Cisco 675 just locked up 
again (third time this week). I have to use a web-mail interface until
I can get home and cycle power on the stupid thing.  I guess it's time
to try upgrading the flash...]
-- 
Grant Edwards
grante@visi.com 

  reply	other threads:[~2001-08-08  8:57 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-07 15:41 [ECOS] " Trenton D. Adams
2001-08-08  0:35 ` Andrew Lunn
2001-08-08  6:27   ` Jonathan Larmour
2001-08-08  6:51     ` Andrew Lunn
2001-08-08  7:13       ` Grant Edwards
2001-08-08  7:52         ` Jonathan Larmour
2001-08-08  8:02           ` Andrew Lunn
2001-08-08  8:06           ` Trenton D. Adams
2001-08-08  8:14             ` Jonathan Larmour
2001-08-08  8:47               ` Trenton D. Adams
2001-08-08  8:58               ` Trenton D. Adams
2001-08-08  9:04                 ` Mark Salter
2001-08-08  9:06                 ` Jonathan Larmour
2001-08-08  9:19                   ` [ECOS] " Grant Edwards
2001-08-08  9:07                 ` Grant Edwards
2001-08-08  8:32             ` [ECOS] " Grant Edwards
2001-08-08  8:43               ` Trenton D. Adams
2001-08-08  8:57                 ` Grant Edwards [this message]
2001-08-08  7:57   ` Trenton D. Adams
2001-08-08  8:09     ` Grant Edwards
2001-08-08  8:14       ` Trenton D. Adams
2001-08-08  8:42         ` Grant Edwards
2001-08-08  8:21     ` Andrew Lunn
2001-08-08  8:27       ` Trenton D. Adams
2001-08-08  9:00       ` [ECOS] " Grant Edwards

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=20010808155704.20E397A926@visi.com \
    --to=grante@visi.com \
    --cc=andrew.lunn@ascom.ch \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=jlarmour@redhat.com \
    --cc=tadams@theone.dnsalias.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).