On Dec 19,  9:55pm, Peter Seebach wrote:
} Subject: Re: C Language Standard(s)
} Hardly makework.  Standards conformance is one of the thing on which
} an OS is judged.

So is performance.

} Yes, it's hard work.  So was getting the system to work on both
} little endian and big endian machines.  So was getting 64 bit
} types to work on 32 bit machines.  The change to ffs was effort,
} and broke code and systems.
} 
} Consider, though - so far, the majority of the problems I've seen with
} using gcc 2.7.2 have been specifically because we were using long long,
} and not just making long be 64 bits.  strtoq wouldn't even exist if
} long were, as expected, the largest integer type.
} 
} Yes, it's work.  No one's proposed that one of the core members just take
} a couple of hours to do it.
} 
} The real question is, is this a direction we want to go in?  If so, we
} start using int64_t for long long, int32_t for long, int32_t for int,
} and int16_t for short.  Then, when none of our code cares which is which,
} we make the subtle change, and change one (1) header.

Plus all the printf and scanf format strings.

The problem with using the intXX_t typedefs is that it would make NetBSD
a sort of roach motel for code.  It would all have the assumption that
int32_t is really an int and int64_t is really a long because they
would always be printed with %d and %ld.

} Then we start
} fighting 3rd party code.

A lot of which would now perform poorly under NetBSD because it was
written in portable ANSI C and used longs wherever it needed an integer
type at least 32 bits wide.  I bet that the multiplication of two 64 bit
integers takes a lot longer than the multiplication of two 32 bit
integers on most of the platforms that NetBSD has been ported to.  Those
lucky enough to have an Alpha may not care, though.

} Ditto code that expects
} long to be a specific size, or int to be a specific size.  Or thinks
} that the size_t you pass to read(2) will be a long.  ANSI is about 7
} years old by now.  People can write to the standard.

I'm all for the use size_t, off_t, and the proper use of prototypes.  I'm
don't think code should assume any more about the size of longs or ints
than is guaranteed by ANSI.  If the Alpha and Sparc V9 and other ports that
have reasonable hardware support for 64 bit datatypes want to have 64 bit
longs, that's fine by me.  I only object to killing performance on the other
ports where 64 bit datatypes are not well supported by the hardware.