From: Pat LaVarre <p.lavarre@ieee.org>
To: linux-fsdevel@vger.kernel.org
Cc: linux_udf@hpesjro.fc.hp.com
Subject: big-endian udfct_1_0r2
Date: 08 Oct 2003 12:09:04 -0600 [thread overview]
Message-ID: <1065636544.7602.49.camel@patehci2> (raw)
In-Reply-To: <1065635511.7602.38.camel@patehci2>
> http://www.extra.research.philips.com/udf/download.html
> For big endian platforms,
> ENDIAN_SWAP must be defined at compilation time.
Anyone here already working on fixing that feature?
I'm too new myself to know how socially correct C code in linux does
distinguish big-endian from little-endian. Perhaps the first fragment
that leaps to my mind is:
static inline int lil() { int const i = 1; return *(char const *)&i; }
I'm too new to have tried that fragment in many gcc and linux. I would
be disappointed, though not really surprised, to discover that the gcc
of wherever we see udf disks in fact doesn't support that kind of
constant as well as a #define constant. Could be that an initialised
const union of char with int might work better.
Pat LaVarre
next prev parent reply other threads:[~2003-10-08 18:09 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-07 19:02 zeroes read back more often than appended Pat LaVarre
2003-10-07 20:54 ` Pat LaVarre
2003-10-08 3:49 ` Ben Fennema
2003-10-08 16:41 ` Pat LaVarre
2003-10-08 16:47 ` editable udf metadata Pat LaVarre
2003-10-08 17:51 ` Pat LaVarre
2003-10-08 18:09 ` Pat LaVarre [this message]
2003-10-08 18:30 ` big-endian udfct_1_0r2 Matthew Wilcox
[not found] ` <3F8472FE.9040403@lougher.demon.co.uk>
2003-10-08 19:49 ` Matthew Wilcox
2003-10-08 20:43 ` Phillip Lougher
2003-10-21 21:54 ` editable udf metadata Pat LaVarre
2003-10-21 23:17 ` Pat LaVarre
2003-10-23 16:06 ` Pat LaVarre
2003-10-24 21:40 ` Pat LaVarre
2003-10-22 8:15 ` same page access Mark B
2003-10-22 11:21 ` Matthew Wilcox
2003-10-22 17:09 ` Mark B
2003-10-22 17:10 ` Matthew Wilcox
2003-10-08 17:02 ` zeroes read back more often than appended Pat LaVarre
2003-10-08 17:06 ` toggling smp clears x86_mce_p4thermal of make xconfig Pat LaVarre
2003-10-08 17:21 ` zeroes read back more often than appended Pat LaVarre
2003-10-08 16:46 ` soft trace of read/write of drivers/block/loop.c Pat LaVarre
2003-10-08 20:32 ` zeroes read back more often than appended Pat LaVarre
2003-10-09 20:54 ` Pat LaVarre
2003-10-10 0:52 ` Pat LaVarre
2003-10-10 16:39 ` Pat LaVarre
2003-10-10 18:15 ` Pat LaVarre
2003-10-14 0:38 ` Pat LaVarre
2003-10-14 1:48 ` Pat LaVarre
2003-10-20 23:20 ` Pat LaVarre
2003-10-21 14:47 ` Pat LaVarre
2003-10-21 16:46 ` Pat LaVarre
2003-10-21 18:44 ` Pat LaVarre
2003-10-23 18:52 ` Pat LaVarre
2003-10-27 21:55 ` Pat LaVarre
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=1065636544.7602.49.camel@patehci2 \
--to=p.lavarre@ieee.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux_udf@hpesjro.fc.hp.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 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.