[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:
|
| 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
Conflicts: | ||||||||
| Comment by A. Jesse Jiryu Davis [ 17/Apr/15 ] | ||||||||
|
Remove GCC-specific min and max macros: | ||||||||
| 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.) | ||||||||
| 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:
On non-gcc platforms this results in double evaluation of the second expression:
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:
... 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:
so that the macro will fall back on the generic definition of BSON_MAX:
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. |