By: Gabriele Svelto (gabriele.svelto.delete@this.gmail.com), November 6, 2006 3:42 am
Room: Moderated Discussions
Linus Torvalds (torvalds@osdl.org) on 11/3/06 wrote:
---------------------------
>Quite frankly, I don't think it's worth my time arguing
>with you. You're taking a religious stance, not one that
>is based on any kind of logical thinking, and you're
>reinforcing it with lies and self-deception, and ignoring
>my arguments. So I'll answer once more, and then just let
>it go.
That was an obvious bait, I'm sorry you took it so bad but I was deliberately provoking you. I'm sorry, on the net irony is hard to spot without the appropriate stuff. Anyway what I understand perfectly is that from your system-level development POV unaligned stuff is not only common but happens everywhere you have to deal with hardware. If you reread my post however I did explicetely ask for user-level applications code which might have to fiddle with unaligned stuff.
>Happily, I don't need to care what you think. The fact is,
>all truly successful desktop architectures disagree with
>you, and agree with me. So I can tell you "reality bites",
>and leave it at that.
Yeah, but as I mentioned you seem a little bit too focused on the desktop architectures. Reality may bite me for the couple of processors sitting on my desk but the most successful and widely available processor architecture doesn't support unaligned stuff and as you mentioned it did so *silently* back in the day. How do you treat that part of reality?
>Total and utter bullshit.
>
>It's totally trivial and common to generate unaligned
>addresses in C, and it happens all the time. All you need
>is just some dynamic data, and you get things like
>
>
>
>Which is not at all an unusual kind of thing to do for
>incoming data. It's things like this that happen all the
>time for streaming protocols - the data you get is not
>necessarily at all naturally aligned. In fact, maybe it's
>aligned "within" the stream, but the stream itself may be
>coming in with headers that cause the contents to not be
>aligned in memory where you've read them.
I know! But as I mentioned I didn't want to talk about wire-protocols and the like because the OS will take the flak of the unalignment for me and I'll get nice properly aligned data on my side of the fence. Also user-level network code is quickly moving away from C/C++ and into Java and other managed languages, something I am profundly grateful of because of the lower possibility of introducing dumb security bugs in those languages.
>Next you'll tell me that things like this don't matter.
They do, but not for user-level applications. For OSes they certainly do but OSes are not written like user level applications, nor are they designed like them.
>Anyway, I'm not interested. I've seen code like that. I've
>even written it. And if I want code to be portable, I
>either add extra portability crap ("get_unaligned()") or
>if I have control over the protocol or disk layout I might
>add padding by hand, but the fact is, most people wouldn't
>even bother. Few enough projects really even care about
>anything but x86 these days.
Which projects? The ones you use on your desktops or the ones running on your cellphone? Or inside your car? The latter do they definetely do.
>But let's just agree to disagree. I just wish you wouldn't
>come up with these totally ludicrous arguments that
>you can't even generate unaligned data in the first place.
>That's just idiocy.
>
>Next you'll tell me that C-like programming languages are
>"unusual", and that people don't use casts. Bah.
People use casts, people do a lot of casts often moving inside the 'undefined behaviour' without even knowing they do. Look at how many application needed clean-up just because they assumed that sizeof(int) == sizeof(void *). What I was really trying to point to is that unaligned stuff is here to stay, mostly because of hardware, but user-level applications should steer away from it unless people wants to do the whole "Let's adapt to 64-bit pointers" again when they have to move to another architecture.
Gabriele
---------------------------
>Quite frankly, I don't think it's worth my time arguing
>with you. You're taking a religious stance, not one that
>is based on any kind of logical thinking, and you're
>reinforcing it with lies and self-deception, and ignoring
>my arguments. So I'll answer once more, and then just let
>it go.
That was an obvious bait, I'm sorry you took it so bad but I was deliberately provoking you. I'm sorry, on the net irony is hard to spot without the appropriate stuff. Anyway what I understand perfectly is that from your system-level development POV unaligned stuff is not only common but happens everywhere you have to deal with hardware. If you reread my post however I did explicetely ask for user-level applications code which might have to fiddle with unaligned stuff.
>Happily, I don't need to care what you think. The fact is,
>all truly successful desktop architectures disagree with
>you, and agree with me. So I can tell you "reality bites",
>and leave it at that.
Yeah, but as I mentioned you seem a little bit too focused on the desktop architectures. Reality may bite me for the couple of processors sitting on my desk but the most successful and widely available processor architecture doesn't support unaligned stuff and as you mentioned it did so *silently* back in the day. How do you treat that part of reality?
>Total and utter bullshit.
>
>It's totally trivial and common to generate unaligned
>addresses in C, and it happens all the time. All you need
>is just some dynamic data, and you get things like
>
>
>struct packet {
>uint16_t len;
>unsigned char data[];
>};
>
>...
>len = htons(packet->len);
>next = (struct packet *)(len + 2 + (char *)packet);
>...
>
>
>Which is not at all an unusual kind of thing to do for
>incoming data. It's things like this that happen all the
>time for streaming protocols - the data you get is not
>necessarily at all naturally aligned. In fact, maybe it's
>aligned "within" the stream, but the stream itself may be
>coming in with headers that cause the contents to not be
>aligned in memory where you've read them.
I know! But as I mentioned I didn't want to talk about wire-protocols and the like because the OS will take the flak of the unalignment for me and I'll get nice properly aligned data on my side of the fence. Also user-level network code is quickly moving away from C/C++ and into Java and other managed languages, something I am profundly grateful of because of the lower possibility of introducing dumb security bugs in those languages.
>Next you'll tell me that things like this don't matter.
They do, but not for user-level applications. For OSes they certainly do but OSes are not written like user level applications, nor are they designed like them.
>Anyway, I'm not interested. I've seen code like that. I've
>even written it. And if I want code to be portable, I
>either add extra portability crap ("get_unaligned()") or
>if I have control over the protocol or disk layout I might
>add padding by hand, but the fact is, most people wouldn't
>even bother. Few enough projects really even care about
>anything but x86 these days.
Which projects? The ones you use on your desktops or the ones running on your cellphone? Or inside your car? The latter do they definetely do.
>But let's just agree to disagree. I just wish you wouldn't
>come up with these totally ludicrous arguments that
>you can't even generate unaligned data in the first place.
>That's just idiocy.
>
>Next you'll tell me that C-like programming languages are
>"unusual", and that people don't use casts. Bah.
People use casts, people do a lot of casts often moving inside the 'undefined behaviour' without even knowing they do. Look at how many application needed clean-up just because they assumed that sizeof(int) == sizeof(void *). What I was really trying to point to is that unaligned stuff is here to stay, mostly because of hardware, but user-level applications should steer away from it unless people wants to do the whole "Let's adapt to 64-bit pointers" again when they have to move to another architecture.
Gabriele
