I agree that the CSDK should use enum value names with names with some type of prefix. I would suggest something equivalent to a c++ namespace-like name. Possibly OC_LOGLEVEL_ or OC_. The naming and namespace in the c++ code is somewhat inconsistent, so I don't know what the eventual namespace is supposed to be.
Do you have a branch for the windows port? -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Antler, David A Sent: Wednesday, April 06, 2016 2:48 PM To: ???(Uze Choi) <uzchoi at samsung.com>; 'Jon A. Cruz' <jon at joncruz.org>; Chang, Gene <gene.chang at intel.com>; iotivity-dev at lists.iotivity.org Subject: Re: [dev] Error using CSDK logger in objective-C I'm working on the Windows port, and what Jon said about our issue is correct. Our issue with ERROR occurs when we include <Windows.h>, so we used an #undef ERROR hack. See: https://gerrit.iotivity.org/gerrit/#/c/5509/16/resource/csdk/logger/include/logger.h I think a CSDK should avoid name collisions. A possible solution would be to prepend the LogLevel enum values with a prefix (such as "LL_") in all locations, if the maintainers would accept such a giant change. We haven't noticed any issues with the DEBUG define, so I have no requirements around that one. Best, David Antler -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of ???(Uze Choi) Sent: Wednesday, April 6, 2016 1:23 AM To: 'Jon A. Cruz' <jon at joncruz.org>; Chang, Gene <gene.chang at intel.com>; iotivity-dev at lists.iotivity.org Subject: Re: [dev] Error using CSDK logger in objective-C In conclusion, what is the proposal with action plan? On the other hand, without modifying, low-level helper can resolve it reversely. We need the opinion from MS windows port developer. BR, Uze Choi -----Original Message----- From: Jon A. Cruz [mailto:[email protected]] Sent: Wednesday, April 06, 2016 3:45 PM To: ???(Uze Choi); Chang, Gene; iotivity-dev at lists.iotivity.org Subject: Re: [dev] Error using CSDK logger in objective-C The windows build hit their main issue with the "ERROR" enum value. So far I believe we have avoided seeing the DEBUG issue much (aside from Tizen) due to the fact that we are not using a standard build system but instead have rolled our own build system using a set of low-level helpers. The work-around for ERROR was to just undef it and replace it in logger.h. However... that could lead to some very bad and hard to spot side-effects. Long term we definitely need to address this correctly. On Tue, Apr 5, 2016, at 10:31 PM, ???(Uze Choi) wrote: > Instead of the potential problem, specifically error happen in Windows > or Google test? > I need the Chang answer for iOS. I'm curious Chang issue because, we > haven't experienced DEBUG keyword issue in iOS build here. > > BR, Uze Choi > -----Original Message----- > From: Jon A. Cruz [mailto:jon at joncruz.org] > Sent: Wednesday, April 06, 2016 2:19 PM > To: ???(Uze Choi); Chang, Gene; iotivity-dev at lists.iotivity.org > Subject: Re: [dev] Error using CSDK logger in objective-C > > Yes. The problem is that whoever wrote the logger code chose a poor > name that is commonly used for other purposes. > > 'DEBUG' is so common for a build of release vs. debug that it has been > the de facto standard for decades. > > We need to change the logger code to no longer hijack potentially > colliding names. > > In the big-picture the problem is that a code subsystem that was > intended to be used throughout other code did not safely prefix its > names. We need to try to ensure that all names are safe. > > So the short-term fix should not be to force other code to stop using > "DEBUG" because the logger wants it, but to instead fix the logger to > no longer 'steal' the "DEBUG" name. > > > On Tue, Apr 5, 2016, at 09:51 PM, ???(Uze Choi) wrote: > > As a fact, DEBUG is used for build MACRO and enum for LOG together. > > > > Chang and Jon could you make it clear that your problem and concern > > is related with these two or other reserved keyword. > > (iOS, Windows and Google Test) > > > > If the problem is related with DEBUG MACRO in build script and > > source code. We can fix it relatively easy. > > Today I searched DEBUG keyword from whole IoTivity source code for > > #ifdef as follows. > > Debug.h (extlibs\tinydtls):# ifndef DEBUG > > Dtls-client.c (extlibs\tinydtls\examples\contiki):#ifndef DEBUG > > Dtls-server.c (extlibs\tinydtls\examples\contiki):#ifndef DEBUG > > Debug.c (resource\csdk\connectivity\lib\libcoap-4.1.1):# ifndef DEBUG > > Net.c (resource\csdk\connectivity\lib\libcoap-4.1.1):# ifndef > > DEBUG To avoid the conflict, change the DEBUG definition from MACRO > > for #ifdef from upper source code and build script looks easiest way. > > (e.g > > BUILD_DEBUG) > > > > else if your concern and problem is related with other reserved > > keyword beyond these two definitions, we need to think about it > > again as Jon suggested. Redefine the enum with prefix. > > > > Let's clarify the problem first. > > > > BR, Uze Choi > > -----Original Message----- > > From: Jon A. Cruz [mailto:jon at joncruz.org] > > Sent: Wednesday, April 06, 2016 12:50 PM > > To: ???(Uze Choi); Chang, Gene; iotivity-dev at lists.iotivity.org > > Subject: Re: [dev] Error using CSDK logger in objective-C > > > > Yes. Enum values should be cleaned up a bit. I know during certain > > sections initial code reviews called for such prefixing. However, I > > think the logging code was done very early on. > > > > The Windows branch also is hitting problems with these. Additionally > > use of non-prefixed enums and/or macros was one aspect of Google > > Test that many found problematic. So it's not a completely unique > > problem, but there are ways to fix it. > > > > On Mon, Apr 4, 2016, at 05:43 PM, ???(Uze Choi) wrote: > > > As like done in Tizen platform. > > > DLOG_ prefix looks best way to do. > > > > > > #ifdef __TIZEN__ > > > typedef enum { > > > DEBUG = DLOG_DEBUG, > > > INFO = DLOG_INFO, > > > WARNING = DLOG_WARN, > > > ERROR = DLOG_ERROR, > > > FATAL = DLOG_ERROR > > > } LogLevel; > > > #else > > > typedef enum > > > { > > > DEBUG = 0, INFO, WARNING, ERROR, FATAL } LogLevel; #endif > > > > > > Temporary you can switch code for iOS build as like this definition. > > > However, holistic perspective duplication need to be avoid > > > changing enum as like this. > > > > > > BR, Uze Choi > > > -----Original Message----- > > > From: iotivity-dev-bounces at lists.iotivity.org > > > [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of > > > Chang, Gene > > > Sent: Tuesday, April 05, 2016 5:19 AM > > > To: iotivity-dev at lists.iotivity.org > > > Subject: [dev] Error using CSDK logger in objective-C > > > > > > I am working on using iotivity for Mac and iOS and am having a > > > compile problem using logger.h. I?m trying to use the rdpayload.h > > > headers to do some cbor processing in an objective-C SDK. It > > > looks like the problem I?m running into is in the LogLevel enum DEBUG > > > declaration. > > > > > > I think the problem is that on Xcode for Mac/iOS (and probably > > > also VS for windows) DEBUG is already #defined and is causing a > > > conflict in the global namespace for the Iotivity CSDK. Has there > > > been any thought to prefixing the enum declarations to prevent namespace > > > conflicts? > > > > > > Thanks. > > > > > > Gene Chang > > > Support and Enablement Lead > > > Intel > > > gene.chang at intel.com<mailto:gene.chang at intel.com> > > > > > > This e-mail and any attachments are confidential and may be > > > subject to legal or some other professional privilege. They are > > > intended solely for the attention and use of the named addressee(s). > > > If you are not the named addressee(s) you must not use, disclose, > > > retain or reproduce all or any part of the information contained > > > in this e-mail or any attachments. > > > Any unauthorized use or disclosure may be unlawful. If you have > > > received this e-mail by mistake, please inform the sender > > > immediately and delete it and all copies from your system and destroy any > > > hard copies of it. > > > > > > _______________________________________________ > > > iotivity-dev mailing list > > > iotivity-dev at lists.iotivity.org > > > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > > > > > > _______________________________________________ > > > iotivity-dev mailing list > > > iotivity-dev at lists.iotivity.org > > > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > > > > > > -- > > Jon A. Cruz > > jon at joncruz.org > > > > > -- > Jon A. Cruz > jon at joncruz.org > -- Jon A. Cruz jon at joncruz.org _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
