Bug 2517 – compile error on mac due to undefined uint16_t

Bug 2517 - compile error on mac due to undefined uint16_t


Summary:	compile error on mac due to undefined uint16_t

Status:	RESOLVED FIXED

Product:	ns-3
Classification:	Unclassified
Component:	aodv
Version:	ns-3-dev
Hardware:	PC Mac OS

Importance:	P5 enhancement
Assigned To:	ns-bugs

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2016-10-06 11:15 UTC by Brian Swenson
Modified:	2018-05-19 22:18 UTC (History)
CC List:	3 users (show)

See Also:	2911

Attachments
patch to fix (1.04 KB, patch) 2016-12-18 11:48 UTC, Tom Henderson	Details \| Diff
revised patch to fix (796 bytes, patch) 2016-12-18 17:26 UTC, Tom Henderson	Details \| Diff
Show Obsolete (1) Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Brian Swenson 2016-10-06 11:15:10 UTC

Assume it's just missing an include to <stdint.h> or I guess <cstdint>

[1312/1858] Compiling src/aodv/model/aodv-routing-protocol.cc
[1313/1858] Compiling src/olsr/model/olsr-header.cc
[1314/1858] Compiling src/internet-apps/model/radvd-prefix.cc
[1315/1858] Compiling src/stats/model/data-collection-object.cc
[1316/1858] Compiling src/bridge/model/bridge-net-device.cc
[1317/1858] Compiling src/internet/model/ipv4-interface-address.cc
[1318/1858] Compiling build/src/network/bindings/ns3module.cc
[1319/1858] Compiling src/wifi/model/interference-helper.cc
[1320/1858] Compiling src/aodv/model/aodv-dpd.cc
[1321/1858] Compiling src/energy/model/energy-harvester.cc
../src/aodv/model/aodv-routing-protocol.cc:1056:24: error: unexpected type name 'uint16_t': expected expression
      retry = std::pow<uint16_t> (2, rt.GetRreqCnt () - 1) * m_netTraversalTime;
                       ^
../src/aodv/model/aodv-routing-protocol.cc:1056:35: error: expression result unused [-Werror,-Wunused-value]
      retry = std::pow<uint16_t> (2, rt.GetRreqCnt () - 1) * m_netTraversalTime;
                                  ^
2 errors generated.

Comment 1 sebastien.deronne 2016-12-18 05:23:36 UTC

I encountered the same issue when starting from a new repo on my MacOS machine

Comment 2 sebastien.deronne 2016-12-18 06:05:38 UTC

I believe it is an issue related to C++11

Comment 3 Tom Henderson 2016-12-18 11:48:11 UTC

Created attachment 2709 [details]
patch to fix

Comment 4 Tom Henderson 2016-12-18 11:48:45 UTC

patch attached that avoids std::pow usage

Comment 5 sebastien.deronne 2016-12-18 11:58:20 UTC

Thanks. Why do you initializeTime retry to m_netTraversalTime, this will get anyway overwritten?

Comment 6 Tom Henderson 2016-12-18 12:27:20 UTC

(In reply to sebastien.deronne from comment #5)
> Thanks. Why do you initializeTime retry to m_netTraversalTime, this will get
> anyway overwritten?

for the case when (rt.GetRreqCnt () <= 1)

Comment 7 Tommaso Pecorella 2016-12-18 13:37:37 UTC

Tbh, GetRreqCnt returns a uint8_t. As a consequence if it's <= 1 it's either 0 or 1.
If it's zero we should raise an assert.
If it's 1, then "(1 << backoffFactor)" is 1 and the result what we would expect.

Summarizing, using an if is a matter of personal taste in the code, I'm totally neutral.


(In reply to Tom Henderson from comment #6)
> (In reply to sebastien.deronne from comment #5)
> > Thanks. Why do you initializeTime retry to m_netTraversalTime, this will get
> > anyway overwritten?
> 
> for the case when (rt.GetRreqCnt () <= 1)

Comment 8 Tom Henderson 2016-12-18 17:26:14 UTC

Created attachment 2710 [details]
revised patch to fix

revised patch to address the comments received

Comment 9 Tom Henderson 2017-12-08 19:47:18 UTC

I will push shortly if no other comments.

Comment 10 Tom Henderson 2018-05-19 22:18:30 UTC

pushed in 13554:cf0f581e4155