Re:

space application and performing our tests there. Over time, as we have increased our code coverage of the unit tests, we’re noticing a pretty strong upward trend of the number of compiler conditionals required to support cross-compiling between a kext and a user-space app. For example: ... #ifdef UNIT_TEST str = (char*) malloc(sz); #else str = (char*) OSMalloc(sz, gOSMallocTag); #endif ... Suffice it to say, we’re wondering if there’s a better way. Ideally, we would like to unit test the code that’s actually running in production. These compiler-level conditionals force us to essentially maintain two versions of our code. Worse than that, the unit tested version is not the production version.

The following is not a kext/Mac/platform-specific suggestion, but... When I encounter this, I move the code into a (hopefully small) module of routines that tend to vary (or not exist) from platform to platform and then use "cover functions" to access them. E.g., str = ss_malloc (sz); ...which gets implemented as one of the two different malloc's you show. So, my "ss_read" and "ss_seek", for example, take a guaranteed int64_t #bytes, and returns a guaranteed int64_t result ... no worrying about int vs. size_t vs. ssize_t vs. offset_t, for example. And, no worrying about whether I need to call read or read64 (or lseek / lseek64), which I used to have to worry about on some platforms. (Inspired, years ago, by Terry Winograd's "Breaking The Complexity Barrier, Again" article :) Stan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com