On Tue, 2006-02-21 at 16:44 -0800, Russ Allbery wrote: > The sad part is that if it's just an issue with duplicate case statements, > it's a two-line fix. > > case ENOTSUP: > case EOPNOTSUPP: > > becomes: > > case ENOTSUP: > #if ENOTSUP != EOPNOTSUPP > case EOPNOTSUPP: > #endif First, the code is script generated, so it's not quite as easy as it seems. But yes, I could fix it, if by fix you mean: fix (vb.): 1. to paper over, obscure, hide from public view; 2. to work around, in a way that produces unintended consequences that are worse than the original problem. Usage: "Windows ME fixes many of the shortcomings of Windows 98 SE". - Hutchison Second, glibc claims (as I have just shown in another message) that it conforms to POSIX 1003.1-2001. Therefore, currently I can expect that the errors are different. Anyway, I don't want to have to work around every Unix's bugs. If I did that, then I'd have to provide my own copy of memcmp (yes, memcmp), because SunOS 4.1.3 (IIRC) compares the bytes as signed, not unsigned. Some versions of AIX have a broken strnlen, which would have to be fixed if I used it (I don't). Half of my code would be fixes for obviously non-standard-conformant behavior[0], and sometimes I'd have to break standards conformance even further[1]. Such fixes are not fun to write; I'd much rather be implementing new features. [0] I once wrote a library called libsus, which wrapped every function in SUSv3 with a libsus_* prefix. It was not fun to implement, and I recently gave up. [1] SunOS 4 and possibly some early versions of SunOS 5 (Solaris 2.x) use the preprocessor macro "sparc", but do not define "__sparc" or "__sparc__". Therefore, I would have to hope that people using my header files would not use "sparc" for something else. Relying on reasonable behavior from users of your library is a bad idea, I have found.
Attachment:
signature.asc
Description: This is a digitally signed message part