Greg Hudson <ghud...@mit.edu> writes: > I'm not immediately sure how to write the autoconf test, though. My > hope is that passing socklen_t * as the final getsockopt argument > generates a warning on HPUX (perhaps you can verify this), and we can > use that to distinguish. But AC_COMPILE_IFELSE doesn't appear to fail > on warnings, so I'm not sure what the best autoconf idiom is to look for > warnings.
Redeclaring getsockopt() with an incompatible type is a constraint violation for which the C standard requires [*] the implementation to produce a diagnostic, so such a redeclaration could be the basis of an autoconf test. (This appears to be roughly the strategy in the message cited below.) > I did find > http://lists.gnu.org/archive/html/autoconf/2007-05/msg00079.html > which works by triyng to to redefine prototypes for accept and connect > to determine whether a system is using socklen_t. But it's pretty > complicated and the author wasn't completely confident in its > correctness at the time. [*] The standard (C99 5.1.1.3) requires the implementation to produce at least one diagnostic, so if the program contains multiple such violations, the standard allows (but does not require) the implementation to produce only one diagnostic, which might not be the specific diagnostic you want. A well-constructed autoconf test should be able to avoid this problem though. I don't know whether the HP/UX compiler makes such a constraint violation a fatal compilation error, but gcc seems to. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos