On Apr 6, 2017 9:27 AM, "Mats Wichmann" <mats at wichmann.us> wrote:
Some of the code that *is* in the C API is bracketed in conditional compilation. For example, ocpayload.h has: #ifdef __WITH_TLS__ bool OCRepPayloadSetPropPubDataType(OCRepPayload *payload, const char *name, const OicSecKey_t *value); bool OCRepPayloadSetPropPubDataTypeAsOwner(OCRepPayload *payload, const char *name, const OicSecKey_t *value); bool OCRepPayloadGetPropPubDataType(const OCRepPayload *payload, const char *name, OicSecKey_t *value); #endif I'm not really fond of the idea that the API has different components depending on how the stack has been compiled. agree in general, but esp. in case of embedded stuff sometimes we want to be able to pick and choose stuff at compile time. i see 2 options: use #ifdefs so the makefile selects the chunks it wants from within compilation units (current impl), or make each compilation unit all-or-nothing, so the makefile selects what to compile and link. if you want the WITH_TLS stuff you compile and link tls_support.c (or whatever). but then what if the kernel makes #ifdeffed calls into tls_support.c? maybe such calls should be macros that can be nulled, just like logging calls, i dunno. Do we want to do this? Or is it better to stub out functions if they don't apply - that is, the above three would be present but return some form of "not implemented" error if called? personally i think i'd prefer a link error or some such. -gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170406/352d9ae1/attachment.html>
