[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OT: Portability (Re: tuxracer...2)

Michel =?iso-8859- writes:
> "Albert D. Cahalan" wrote:
>> Michel =?iso-8859- writes:
>>> Jens Schmalzing wrote:
>>>> Michel D\344nzer writes:

>>>>> Which one would that be? BenH told me the offset text is caused
>>>>> by the dreaded (un)signed char issue.
>>>> Precisely that.  And therefore, it wasn't a big deal to fix.
>>>> But since I made a package for my personal use out of it,
>>>> why not share it with others.
>>> Have you fixed it properly or just with -fsigned-char?
>> "properly"?
>> The "signed" keyword is new, added by the same committee that
>> came up with trigraphs. This is all about kissing IBM's butt
>> for EBCDIC-encrypted text on IBM mainframes and minicomputers.
>> Proper UNIX systems use a signed char. PowerPC Linux gets an
>> unsigned char from AIX, which gets it from being done by IBM.
>> Ugh. The proper fix involves changing your gcc spec file.
> Show me a standard which defines char as being signed and I'll
> happily file a bug against gcc.
> At least we seem to agree that -fsigned-char isn't a solution. ;)
>> While I'm at it, PowerPC chips can handle the correct byte order.
> 'Correct'? While I much prefer big endian (the only advantage of
> little endian seems to be for hiding bad code), I don't pretend
> being able to judge which one is 'correct'.
> If you prefer little endian, you are free to start a little endian
> port of the Linux kernel for PowerPC or use different OSs and/or
> hardware.
>> We bring these portability problems on ourselves.
> I strongly disagree. Code relying on broken assumptions is simply broken.

Nearly all code is broken then, because POSIX+C would allow:

9 bits per char
sizeof(int)==3, with 2-char alignment
sizeof(long)==5, with 7-char alignment
byte order that is 1,3,2 and 2,1,5,3,4
SIGFPE on integer overflow
an integer NaN that can cause SIGFPE when used
lack of setuid, symlinks, and long filenames
base-42 floating-point numbers
no way to type '{' characters

What should we call this... "going against the flow"?

Sometimes the differences are useful. For example, Linux can do
things that Windows can't do, and PowerPC chips run cool. Other
times the differences are just pointless and painful. Having an
unsigned char is just pointless and painful. It could be fixed.

Fixing the byte-order problem is damn near impossible due to the
existing user base. Oh well. (Actually I will be running Linux this
way for an embedded system, just like the guys at Matrox do.)

Reply to: