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 :)



> 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

Reply via email to