To read all comments associated with this story, please click here.
Endiness isn't that big of a problem. You have what: two possibilities?
And why on earth would I want to use a language that lets the programmer deal with it instead of doing it itself? I can't think of any situation where as a programmer you would want to have the endianess differences exposed to your programs (not even in drivers). Just make everything be big endian in source code level and let the compiler figure out how put that in machine language.
Also, null terminated byte arrays are a library convention. It's not a language feature. If you want to manipulate unicode, use the proper library.
So, no portable strings in C? It's only portable when I rely on the standard C library, which uses null-terminated strings. When I have to rely on other libraries, I lose the (supposed) portability.
> So, no portable strings in C? It's only portable when I rely on the standard C library, which uses null-terminated strings. When I have to rely on other libraries, I lose the (supposed) portability.
If you change an API, I have to admit it is quite hard not to change the program...
And why on earth would I want to use a language that lets the programmer deal with it instead of doing it itself? I can't think of any situation where as a programmer you would want to have the endianess differences exposed to your programs (not even in drivers).
You're going to want endianess differences exposed whenever you're dealing with a binary encoding. This includes various binary encodings for network protocols, video and audio encodings and even the bytecode which a JVM or .Net runtime needs to decode. If the compiler automatically enforced the endianess of the hardware (and some hardware allows you to change the endianess, what then?) how would you go about encoding or decoding such binary protocols?
Besides encoding and decoding binary protocols, when would a programmer even worry about endian issues anyways? I can't think of one time that I was actually bothered by that in normal application code.
Well, I believe things like strcat are defined in ansi c, and they use null terminated strings.
However, most of the ansi-c libs are tiny and pretty easy to rewrite. So yea, you could certainly define your own string struct and libs to deal with it.
I think if you're having an endiness problem, well, QUIT USING THE SHIFT OPERATOR; or prepare to write that code over for every platform (not that big a deal).





Member since:
2005-07-06
What it sounds like you're saying is, "Gee, if everyone just wrote their programs for x runtime, everything would be peachy." Isn't that the same as arguing that everyone just write for x hardware architecture, and that will solve all portablity problems?
I don't think moving the portablity problem from hardware to x virtual machine is a silver bullet. It just moves the problem somewhere else. Porting VMs is sometimes more difficult than just porting the program that would have run on it on the first place.
Endiness isn't that big of a problem. You have what: two possibilities? Most portability problems in C result from misuse/understanding of types or making broad assumptions.
Also, null terminated byte arrays are a library convention. It's not a language feature. If you want to manipulate unicode, use the proper library.
Now, don't go on a flame fest just yet. I don't advocate using C for large application programs. I'm definately in the python/lisp camp; however, I don't blame C for begin deficient for features (or the lack of them) that were specifically meant to model the hardware closely. Richie wasn't a moron after all.