long long vs int64_t

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at osmocom.org
Wed Sep 15 10:22:20 UTC 2021


Hi Neels,

On Wed, Sep 15, 2021 at 08:18:52AM +0200, Neels Hofmeyr wrote:
> On Wed, Sep 15, 2021 at 02:45:42AM +0000, scan-admin at coverity.com wrote:
> > >>>     CID 240103:    (CONSTANT_EXPRESSION_RESULT)
> > >>>     "val < -9223372036854775808LL /* -9223372036854775807L - 1 */" is always false regardless of the values of its operands. This occurs as the logical operand of "if".
> > 1434     	if (val < INT64_MIN) {
> > 1435     		if (result)
> > 1436     			*result = INT64_MIN;
> > 1437     		return -ERANGE;
> > 1438     	}
> 
> Yes I know, but is it guaranteed on all archs in past and future that long long int is 64 bit?

it seems anything except IBM 370, PDP-11 etc. from that area (which has no long long)
has long long int as 64bit in the future who knows, maybe it gets even longer, who knows.

> I'd just ignore these warnings if that's ok with everyone else.

Wouldn't they go away with a simple change from INT64_MIN/MAX to LLONG_MIN/MAX?

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list