I personally like macros that that check for errors conditions and that goto
exit on error, where resources can be cleaned up. I think one thing missing
from the existing macros was the ability to log issues, so I recently created
VERIFY_OR_LOG_AND_EXIT which I have been happily using, for example
ret = mbedtls_x509write_crt_pem(&outCertCtx, (uint8_t *)buf, sizeof(buf),
mbedtls_ctr_drbg_random, &ctr_drbg);
VERIFY_OR_LOG_AND_EXIT(TAG, 0 == ret, "Could not generate pem buffer for
internal cert generation", ERROR);
To me the code that takes this approach is clean and simple to read, and more
consistent with respect to cleanup.
I for one would not want to lose those macros for production code :)
Cheers!
Steve
> On Mar 6, 2018, at 12:42 PM, Mats Wichmann <m...@wichmann.us> wrote:
>
> On 03/06/2018 12:38 PM, Nash, George wrote:
>> I am not a fan of the VERIFY_SUCCESS macro. It is not prefixed with the OC_
>> which should be used for all iotivity macros to help prevent name collisions
>> with macros from external projects. Even with the prefix I think this is an
>> internal macro that should not be exposed to the public APIs. I have seen
>> some code recently that used the VERIFY_SUCCESS macro in sample code. The
>> only reason it is building is because it is linking with internal headers.
>> (not 100% sure about the non-public API statement)
>>
>> We definitely should check where it is defined in multiple places and see if
>> we can consolidate those definitions to a single definition. If we cannot
>> consolidate to one definition I would rename one of the usages.
>>
>> Finally if nothing else works the #ifdef #undef // macro #endif option
>> should be applied.
>>
>> This is all opinion and I am open to other suggestions.
>>
>> George Nash
>
> the VERY_FUNNY (oops, VERIFY_SUCCESS) stuff should only be used for unit
> tests, no? that style of macro would be pretty ugly for non-test code
> anyway as there tend to be embeded returns/goto-exits/etc in at least
> some of the series. Production code, and even examples, would want to
> handle errors, not just bail.
> _______________________________________________
> iotivity-dev mailing list
> iotivity-dev@lists.iotivity.org
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
_______________________________________________
iotivity-dev mailing list
iotivity-dev@lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
