Cenk Gündoğan

Can't do much testing here but could you try moving `buf` outside the function scope? E.g., as a global variable.

theoretically yes, but once the function `ccnl_mkInterest()` returns, the `opts` value is never used again. It's only used for marshalling the packet in `ccnl_ndntlv_prependInterest`. No references are saved for later...

IMHO, removing NFN code from CCN-lite has many advantages. As @blacksheeep pointed out, we can get rid of many `#ifdefs` and it makes no sense to keep unmaintained code in...

Yes, I also agree on this. We should definitely use RIOTs community processes as a basis to come up with some simple rules and practices. Another important step for community...

@blacksheeep oh okay. How can I subscribe there?

for reference: https://github.com/cn-uofbasel/ccn-lite/blob/master/src/ccnl-core/src/ccnl-prefix.c#L557

>You mean a lock free memory allocator which allocates memory from a pre-defined memory block? sounds like malloc to me (:

the first thing would be to evaluate, if there are any calls to `_path_detailed()` from API functions. If not, then there's no problem at all.

>and I think ccn-lite in the long run should support multi-threading/parallel access do you mean the ccn-lite core (or forwarding daemon) should support multi-threadding? Or should the user API just...

>do you mean the ccn-lite core (or forwarding daemon) should support multi-threadding? Or should the user API just be thread-safe? From the perspective of RIOT, making the forwarder multi-threaded is...