[SERVER-9680] Invalid use of negative enumeration on type not declared as signed Created: 14/May/13  Updated: 11/Jul/16  Resolved: 04/Jun/13

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5.1

Type: Bug Priority: Major - P3
Reporter: Robie Basak Assignee: Andrew Morrow (Inactive)
Resolution: Done Votes: 0
Labels: pull-request
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: Linux
Steps To Reproduce:

Attempt to build on armhf.

Participants:

 Description   

MinKey is defined as -1, so a signed char must be used to store BSONType
enumerations. Using a char to store a negative value results in
undefined behaviour. On i386 and amd64 architectures it happens to work
because on these platforms a char is generally signed, but this is not
guaranteed.



 Comments   
Comment by auto [ 04/Jun/13 ]

Author:

{u'name': u'Robie Basak', u'email': u'robie.basak@canonical.com'}

Message: SERVER-9680 Use a signed char to store BSONType enumerations

MinKey is defined as -1, so a signed char must be used to store BSONType
enumerations. Using a char to store a negative value results in
undefined behaviour. On i386 and amd64 architectures it happens to work
because on these platforms a char is generally signed, but this is not
guaranteed.

This fixes a build failure on ARM, where chars are unsigned by default,
and using MinKey (defined as -1) results in a compiler error.

Signed-off-by: Andrew Morrow <acm@10gen.com>
Branch: master
https://github.com/mongodb/mongo/commit/7c151707ca81af0ade246bb181f1b424ae6b9a4f

Comment by Robie Basak [ 01/Jun/13 ]

> Does the ARM compiler have an option to treat char as signed by default?

Yes - you can use -fsigned-char and modify your build system to suit. This should work.

However, char is specified in the C standard as of undefined signedness, so you'd be depending on gcc and your build system to be able to build unportable/nonstandard C.

IMHO, a better long term solution is to fix your code base to be portable where possible, and to ban unportable/undefined/nonstandard code from your code base except where absolutely necessary. This is certainly one area where this is trivial to do, and fixes the problem.

If it turns out that there are other areas in the code where using "char" has led to buggy code due to a "signed" assumption, and this has gone undetected, then maybe we can use -fsigned-char as a workaround with a view to improving test coverage?

Comment by Tad Marshall [ 01/Jun/13 ]

I think the codebase assumes that char is signed pretty much throughout, although it may not matter in most places. We certainly specify unsigned in the places where we want unsigned.

Does the ARM compiler have an option to treat char as signed by default? Wouldn't that be a more effective way to address the problem?

Generated at Thu Feb 08 03:21:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.