[CDRIVER-613] ANSI C warnings Created: 11/Apr/15  Updated: 08/Jan/24  Resolved: 19/Apr/15

Status: Closed
Project: C Driver
Component/s: None
Affects Version/s: None
Fix Version/s: 1.1.5

Type: Bug Priority: Major - P3
Reporter: Jeroen Ooms [X] Assignee: A. Jesse Jiryu Davis
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I am trying to publish a R drivers based on mongoc-driver, however the repository maintainers told me I need to take care of these warnings to be ISO C compliant:

* checking whether package ‘mongolite’ can be installed ... WARNING
Found the following significant warnings:
  bson/bson-macros.h:103:26: warning: ISO C forbids braced-groups within expressions [-Wpedantic]
  bson/bson-macros.h:86:26: warning: ISO C forbids braced-groups within expressions [-Wpedantic]
  mongoc/mongoc-stream-tls.c:572:47: warning: pointer of type ‘void *’ used in arithmetic [-Wpointer-arith]



 Comments   
Comment by Githook User [ 07/Oct/15 ]

Author:

{u'username': u'ajdavis', u'name': u'A. Jesse Jiryu Davis', u'email': u'jesse@mongodb.com'}

Message: Merge branch 'master' into 1.2.0-dev

  • master:
    add prerelease version to CMakeLists
    wrap version definitions in parens
    check for prerelease version with m4_ifset
    grammar
    CDRIVER-624 fix clang version check
    CDRIVER-624 fix gcc and clang version checks
    Silence CMake 3.0+ warning on Mac OS X.
    CDRIVER-613 remove GCC-specific min/max macros.

Conflicts:
CMakeLists.txt
build/autotools/Versions.m4
doc/version.page
Branch: master
https://github.com/mongodb/libbson/commit/ce961137ad3e51a2e3688a2e024dc1918f2f71be

Comment by A. Jesse Jiryu Davis [ 17/Apr/15 ]

Remove GCC-specific min and max macros:

https://github.com/mongodb/libbson/pull/123

Comment by A. Jesse Jiryu Davis [ 17/Apr/15 ]

Jeroenooms's pull request for the void pointer issue. (GCC treats void pointer as a char pointer for the sake of pointer arithmetic, other compilers warn or fail since void pointer's target has no defined size.)

https://github.com/mongodb/mongo-c-driver/pull/220

Comment by Jeroen Ooms [X] [ 17/Apr/15 ]

Any decision on this?

Comment by A. Jesse Jiryu Davis [ 13/Apr/15 ]

Thanks, I completely agree. I'll wait for my colleagues, who are more experienced with the driver, to comment. But I'm inclined to remove the GCC-specific code for exactly this reason.

Comment by Jeroen Ooms [X] [ 13/Apr/15 ]

One argument for removing the gcc-specific definition is to avoid compiler inconsistencies which could hide platform specific bugs. For example you are using:

BSON_MAX(0, bson_iter_int32(&iter));

On non-gcc platforms this results in double evaluation of the second expression:

((0) > (bson_iter_int32(&iter)) ? (0) : (bson_iter_int32(&iter)))

This case is harmless, but if you were to insert an expression with side effects, you will get different behavior with different compilers. On non-gcc compilers the double evaluation could introduce a bug, but if you are developing in a gcc environment you won't notice because the gcc-specific macro saves you.

Comment by A. Jesse Jiryu Davis [ 12/Apr/15 ]

Confusingly, clang defines __GNUC__ and other GCC preprocessor variables, although of course it's not perfectly compatible with GCC, as you see. We could do:

#if defined(__GNUC__) && !defined(__clang__)

... or just remove the GCC-specific definitions of BSON_MIN and BSON_MAX as you suggest. Let me check with my colleagues about their opinions.

Comment by Jeroen Ooms [X] [ 11/Apr/15 ]

As a workaround, can I just remove the entire GNU specific block:

#elif defined(__GNUC__)
#  define BSON_MAX(a, b) ({     \
                        __typeof__ (a)_a = (a); \
                        __typeof__ (b)_b = (b); \
                        _a > _b ? _a : _b;   \
                     })

so that the macro will fall back on the generic definition of BSON_MAX:

#else
#  define BSON_MAX(a, b) (((a) > (b)) ? (a) : (b))

or will this have side effects?

Comment by Jeroen Ooms [X] [ 11/Apr/15 ]

These GNU extensions actually appear within a `#elif defined(_GNUC_)` block but gcc doesn't care about that.

Generated at Wed Feb 07 21:10:03 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.