// The low word contains a Language Identifier for the input language
// and the high word contains a device handle to the physical layout
// of the keyboard.
localeId &= 0xffff; // mask off high word to get the locale
// identifier

Recently I have to do a lot of C# programming. It’s a quite ok language to be honest. I need to wrap certain unsafe code in C# code. Some of this unsafe code uses the old type UCHAR, which is defined as an unsigned char type with a limit of 0 to 255, inclusive. Perusing some websites to look for some marshaling information I actually find people recommending using the sbyte data type for this. This datatype (sbyte, SByte or the full System.SByte) is a signed 8-bit integer type. This means it has a range of -128 to 127. This is also extensively documented in the sbyte C# reference. So I am left wondering how well these programmers actually do understand their data types.

Was converting files to proper ANSI C function declarations and a user tripped over the fact that old 4.4 BSD’s function prototype of strmode() had int as a parameter, whereas it has been mode_t for a long, long time (read 1994 at least).

This broke buildworld of course.

Also asked Dima Dorfman to fix this for FreeBSD (broken in 4.x, 5.x, and 6.x).

NetBSD is fixed (as was to be expected to be honest).

And OpenBSD made the parameter int everywhere with a XXX comment in the strmode.c file that it should be mode_t actually. Weird.