On 03/06/2018 09:19 AM, Heldt-Sheller, Nathan wrote:
> Hi Devs,
> I've noticed that we define macros (e.g. VERIFY_SUCCESS, and similar) in 
> several places, usually in the source file where it's being used.  This seems 
> like a maintenance burden and bug risk (if two implementations differ, it 
> might lead a developer to make a mistake).  It also can lead to collisions 
> when the macro appears in a header and source file.
> One approach would be to wrap the macros in #ifndef //macro #endif blocks, to 
> resolve potential collisions, but again this seems error-prone, as a dev may 
> not know which version is actually being used when calling.
> Another approach would be to wrap the macros in local source files with 
> #ifdef #undef // macro #endif blocks to ensure the locally-defined version is 
> used.
> Another approach is to remove the implementations from source files entirely 
> and place in a shared "verifymacros.h" header file, but this would touch a 
> lot of files.
> I'm sure there are others, too...
> Any thoughts?

there's other duplication as well in the tree, which probably won't come
as a surprise to people who've looked around a bit.

most of the macros seem to be in headers already, we should encourage
that, although in some cases better choices could be made.  For the one
you mention here's (slightly out of date) the stored information from my
tags file, trimmed:

resource/csdk/security/include/srmutility.h, line 62
cloud/samples/client/thin_light/thin_room_light.cpp, line 47
plugins/samples/linux/IotivityandZigbeeServer.c, line 31
resource/csdk/stack/samples/linux/SimpleClientServer/occlient.cpp, line 50
resource/csdk/stack/samples/linux/SimpleClientServer/ocserver.cpp, line 48
resource/csdk/stack/samples/tizen/SimpleClientServer/ocserver.cpp, line 39
resource/csdk/stack/src/ocresource.c, line 72
resource/csdk/stack/src/ocstack.c, line 180
resource/csdk/stack/src/oickeepalive.c, line 46

This isn't great.

There are really two flavors of this one, the C form and the C++ form,
with some variation across those.

I've thought about playing with some tools to flush out
redundancies/inefficiencies, but nobody's paying me for working on this
and the motivation just isn't always there. (sorry)

iotivity-dev mailing list

Reply via email to