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
[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
16 matches
Mail list logo
