In article <199601100806.DAA12548@Collatz.McRCIM.McGill.EDU> mouse@Collatz.McRCIM.McGill.EDU (der Mouse) writes:
>
>Are you sure you'd realize it?  If you wrote anything using comp_t,
>dev_t, uid_t, or gid_t, well, those are sub-int on my NeXT at home.  On
>the Suns at work, those plus mode_t, nlink_t, and wchar_t.  On
>NetBSD/sun3, I didn't find any *_t types that were really shorts.
>
>> Thus for me old-style defintions lose me nothing - my code always
>> behaves correctly.  And I get maximum portability of my code.
>
>For maximum portability, you must be using the *_t types...and if you
>ever pass them directly, you're using sub-int types without realizing
>it, and worse, you're doing so on only some platforms.
>
>> Not if you fill the code base with 
>> char foo(short x) {...}
>> when you convert that sort of thing back to K&R you will have a _lot_
>> of work to do to debug it.
>
>Um, you will in any case, and gcc has warning options (-Wconversion) to
>help find danger spots.
>

Well, in my opinion you really want your library interfaces to contain
functions that only use integral types as arguments. Otherwise you'll
need two copies of the library, one to be used with ansi compilers and
one to be used without. As for the argument that mode_t, dev_t, uid_t,
gid_t should be used for maximum portability, I've seen it break on
SunOS-4.x. with early versions of unbundled ansi compiler where the
headers would declare systems calls taking mode_t arguments while the
libraries were expecting ints...

As I mentioned above, there is usually no good reason to pass non 
integral arguments [except in the float/double case] and for maximal
portability libraries should be designed that way.

christos