Hi!
> > I was looking over the iso9660 code, and noticed that it was doing
> > endianness conversion via ad hoc *functions*, not even inlines; nor did
> > it take any advantage of the fact that iso9660 is bi-endian (has "all"
> > data in both bigendian and littleendian format.)
> >
> > The attac
On Thu, 3 May 2001, Albert D. Cahalan wrote:
> Pavel Machek writes:
>
> > It should ot break anything. gcc decides its bad to inline it, so it
> > does not inline it. Small code growth at worst. Compiler has right to
> > make your code bigger or slower, if it decides to do so.
>
> Oh come on. Th
Pavel Machek writes:
> It should ot break anything. gcc decides its bad to inline it, so it
> does not inline it. Small code growth at worst. Compiler has right to
> make your code bigger or slower, if it decides to do so.
Oh come on. The logical way:
inline Compiler must inline (only
Hi!
> > > The attached patch fixes both. It is against 2.4.4, but from the looks
> > > of it it should patch against -ac as well.
> >
> > Btw, please use "static inline" instead of "extern inline", as gcc may
> > decide not to inline the latter at all, leading to confusing link-time
> > errors.
Martin Dalecki wrote:
>
> "H. Peter Anvin" wrote:
> >
> > Hi guys,
> >
> > I was looking over the iso9660 code, and noticed that it was doing
> > endianness conversion via ad hoc *functions*, not even inlines; nor did
> > it take any advantage of the fact that iso9660 is bi-endian (has "all"
> >
"H. Peter Anvin" wrote:
>
> Hi guys,
>
> I was looking over the iso9660 code, and noticed that it was doing
> endianness conversion via ad hoc *functions*, not even inlines; nor did
> it take any advantage of the fact that iso9660 is bi-endian (has "all"
> data in both bigendian and littleendian
Linus Torvalds wrote:
>
> On Tue, 1 May 2001, H. Peter Anvin wrote:
> >
> > Oh bother, you're right of course. We need some kind of standardized
> > macro for indirecting through a potentially unaligned pointer.
>
> No we don't - because it already exists.
>
> It's called "get_unaligned()".
>
On Tue, 1 May 2001, H. Peter Anvin wrote:
>
> Oh bother, you're right of course. We need some kind of standardized
> macro for indirecting through a potentially unaligned pointer.
No we don't - because it already exists.
It's called "get_unaligned()".
Linus
-
To unsubscribe
> Oh bother, you're right of course. We need some kind of standardized
> macro for indirecting through a potentially unaligned pointer. It can
get_unaligned()
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Okay, this one should actually work as advertised. Pardon the mental
meltdown earlier.
This also changes "extern inline" to "static inline" (per Linus' request)
and always ignores the bigendian part of a bi-endian datum (per Tim
Riker's observation that lots of [Windoze?] programs get that wrong
[EMAIL PROTECTED] wrote:
>
> Oh bother, you're right of course. We need some kind of standardized
> macro for indirecting through a potentially unaligned pointer. It can
> just do the dereference (e.g. x86), use left/right accesses (e.g. MIPS),
> or do it by byte (others).
>
> Ports people, wh
Andrzej Krzysztofowicz wrote:
>
> Are you sure that the arguments of the following casting
>
> > + return le16_to_cpu(*(u16 *)p);
>
> > + return be16_to_cpu(*(u16 *)p);
>
> > + return le32_to_cpu(*(u32 *)p);
>
> > + return be32_to_cpu(*(u32 *)p);
>
> are properly aligned ?
>
Are you sure that the arguments of the following casting
> + return le16_to_cpu(*(u16 *)p);
> + return be16_to_cpu(*(u16 *)p);
> + return le32_to_cpu(*(u32 *)p);
> + return be32_to_cpu(*(u32 *)p);
are properly aligned ?
I did not revise the code to check it, but AFAIK imprope
hpa,
I'd remove the __BIG_ENDIAN test cases if I were you. Having written
many a iso9660 decoder I will tell you that the "required" bi-endian
implementation is sometimes broken as many vendors only test CDs with a
certain single endian OS. I've seen these set to 0s, or -1 or just a
copy of the l
Linus Torvalds writes:
> Btw, please use "static inline" instead of "extern inline", as gcc may
> decide not to inline the latter at all, leading to confusing link-time
> errors. (Gcc may also decide not to inline "static inline", but then gcc
> will output the actual body of the function out-of-
Linus Torvalds wrote:
>
> On Mon, 30 Apr 2001, H. Peter Anvin wrote:
> >
> > The attached patch fixes both. It is against 2.4.4, but from the looks
> > of it it should patch against -ac as well.
>
> Btw, please use "static inline" instead of "extern inline", as gcc may
> decide not to inline th
On Mon, 30 Apr 2001, H. Peter Anvin wrote:
>
> The attached patch fixes both. It is against 2.4.4, but from the looks
> of it it should patch against -ac as well.
Btw, please use "static inline" instead of "extern inline", as gcc may
decide not to inline the latter at all, leading to confusing
Hi guys,
I was looking over the iso9660 code, and noticed that it was doing
endianness conversion via ad hoc *functions*, not even inlines; nor did
it take any advantage of the fact that iso9660 is bi-endian (has "all"
data in both bigendian and littleendian format.)
The attached patch fixes bot
18 matches
Mail list logo
