I prefer this concept also. We can apply this rule in case of invalid parameter for specific compile option.
Then, in case of bool/void return, how can we return ?not implemented? error code? BR, Uze Choi From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Junghyun Oh Sent: Friday, April 07, 2017 1:57 PM To: Mats Wichmann Cc: IoTivity Developer List Subject: Re: [dev] C API: conditional code +1 on "stub out functions if they don't apply " 2017. 4. 6. ?? 11:27? "Mats Wichmann" <mats at wichmann.us>?? ??: 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. 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? _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev -------------- next part -------------- HTML ?????? ??????????????... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170407/b19b520b/attachment.html>
