Bug 1472 – Small syntax problems, resulting in build failure using clang compiler

Bug 1472 - Small syntax problems, resulting in build failure using clang compiler


Summary:	Small syntax problems, resulting in build failure using clang compiler

Status:	RESOLVED FIXED

Product:	ns-3
Classification:	Unclassified
Component:	lte
Version:	ns-3-dev
Hardware:	All All

Importance:	P5 normal
Assigned To:	Nicola Baldo

URL:
Keywords:

Depends on:
Blocks:	1345
	Show dependency tree / graph

Reported:	2012-07-11 16:31 UTC by Alex Afanasyev
Modified:	2012-10-03 06:35 UTC (History)
CC List:	2 users (show)

See Also:

Attachments
patch (3.74 KB, patch) 2012-07-11 16:31 UTC, Alex Afanasyev	Details \| Diff
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 Alex Afanasyev 2012-07-11 16:31:21 UTC

Created attachment 1424 [details]
patch

1. Log-related
clang compiler does not allow cout << std::vector<..>(), so the usage was replaced by the address of the vector
    
2. clang does not allow non-POD (non plain-old-data) types to be
allocated on stack. Replaced with heap allocation and deallocation.


Also. The current version of LTE needs bindings rescan. I can supply a patch, but there is no point in it.

Comment 1 Nicola Baldo 2012-07-17 23:12:00 UTC

Hi Alex, 

thanks for the patch, please find my comments below.


(In reply to comment #0)
> Created attachment 1424 [details]
> patch
> 
> 1. Log-related
> clang compiler does not allow cout << std::vector<..>(), so the usage was
> replaced by the address of the vector

I'd just remove activeRbs from the NS_LOG_FUNCTION then, just logging its address does not say much.


> 
> 2. clang does not allow non-POD (non plain-old-data) types to be
> allocated on stack. Replaced with heap allocation and deallocation.
> 

I never used clang, but after a quick google search it seems to me that the issue is not with the fact that the arrays are on the stack, but rather with the fact that the arrays have variable length. 

See also a similar bug description https://www.nsnam.org/bugzilla/﷒0﷓

Would it suffice if you just change numOfPbs and numOfPkts to a const variable (or to a #define) to make the arrays have a constant length?


> 
> Also. The current version of LTE needs bindings rescan. I can supply a patch,
> but there is no point in it.

Tom rescanned the bindings with changeset a11fdda061ae, so this should be fixed now.

Comment 2 Vedran Miletić 2012-09-14 19:07:30 UTC

Fixed in changeset 9077 16e6f501eeef (in a bit different way). If there are pros to this approach compared to one I used I would be glad to hear them.

Comment 3 Nicola Baldo 2012-10-03 06:35:50 UTC

I looked at changeset 16e6f501eeef and I am fine with the changes. Thanks!