Broken code generation for out function parameters - redhawksdr

I made my own interface, simplistic version looks like this:
#ifndef _FOO_IDL_
#define _FOO_IDL_
module FOO {
typedef unsigned long Bar;
interface FOOInterface {
void getBar(out FOO::Bar b);
};
};
#endif
After that I made "REDHAWK IDL Project", used that IDL, compiled, installed.
Then I made Redhawk component, added output port and used that interface on it, did code generation. During compilation I got error:
port_impl.h:26:29: error: expected ‘,’ or ‘...’ before ‘&&’ token
void getBar(FOO::Bar&& b);
It looks like code generator adds excessive ampersand. What could I do about it?
Thank you.

Related

Thread safety of std::cout insertion operator

I've always thought that using std::cout << something was thread safe.
For this little example
#include <iostream>
#include <thread>
void f()
{
std::cout << "Hello from f\n";
}
void g()
{
std::cout << "Hello from g\n";
}
int main()
{
std::thread t1(f);
std::thread t2(g);
t1.join();
t2.join();
}
my expectation was that the order of the two outputs would be undefined (and indeed that is what I observe in practice), but that the calls to operator<< are thread safe.
However, ThreadSanitizer, DRD and Helgrind all seem to give various errors regarding access to std::__1::ios_base::width(long) and std::__1::basic_ios<char, std::__1::char_traits >::fill()
On Compiler Explorer I don't see any errors.
On FreeBSD 13, ThreadSanitizer gives me 3 warnings, the two listed above plus the malloc/memcpy to the underlying i/o buffer.
Again in FreeBSD 13, DRD gives 4 errors, width() and fill() times two for the two threads.
Finally FreeBSD 13 Helgrind gives one known false positive related to TLS in thread creation, fill()and width() twice.
On Fedora 34
No errors with g++ 11.2.1 and ThreadSanitizer
DRD complains about malloc/memcpy in fwrite with g++ compiled exe
Helgrind also complains about fwrite and also for the construction of cout, again with the g++ compiled exe
clang++ 12 ThreadSanitizer complains about fill() and width()
DRD with the clang++ compiler exe complains about fill(), width(), fwrite and one other in start_thread
Helgrind with the clang++ exe complains about some TLS, fill(), width(), fwrite
macOS XCode clang++ ThreadSanitizer generates warnings as well (which will be libc++).
Looking at the libc++ and libstdc++ code I don't see anything at all that protects width(). So I don't understand why there are no complaints on compiler explorer.
I tried running with TSAN_OPTIONS=print_suppressions=1 and there was no more output (g++ Fedora ThreadSanitizer)
There does seem to be some consensus over the width() and fill() calls.
Looking more closely at the libstdc++ source I see that there is
(with some trimming and comments):
// ostream_insert.h
// __n is the length of the string pointed to by __s
template<typename _CharT, typename _Traits>
basic_ostream<_CharT, _Traits>&
__ostream_insert(basic_ostream<_CharT, _Traits>& __out,
const _CharT* __s, streamsize __n)
{
typedef basic_ostream<_CharT, _Traits> __ostream_type;
typedef typename __ostream_type::ios_base __ios_base;
typename __ostream_type::sentry __cerb(__out);
if (__cerb)
{
__try
{
const streamsize __w = __out.width();
if (__w > __n)
{
// snipped
// handle padding
}
else
__ostream_write(__out, __s, __n);
// why no hazard here?
__out.width(0);
}
__out is the stream object, global cout in this case. I don't see anything like locks or atomics.
Any suggestions as to how ThreadSanitizer/g++ is getting a "clean" output?
There is this somewhat cryptic comment
template<typename _CharT, typename _Traits>
basic_ostream<_CharT, _Traits>::sentry::
sentry(basic_ostream<_CharT, _Traits>& __os)
: _M_ok(false), _M_os(__os)
{
// XXX MT
if (__os.tie() && __os.good())
__os.tie()->flush();
The libc++ code looks similar. In iostream
template<class _CharT, class _Traits>
basic_ostream<_CharT, _Traits>&
__put_character_sequence(basic_ostream<_CharT, _Traits>& __os,
const _CharT* __str, size_t __len)
{
#ifndef _LIBCPP_NO_EXCEPTIONS
try
{
#endif // _LIBCPP_NO_EXCEPTIONS
typename basic_ostream<_CharT, _Traits>::sentry __s(__os);
if (__s)
{
typedef ostreambuf_iterator<_CharT, _Traits> _Ip;
if (__pad_and_output(_Ip(__os),
__str,
(__os.flags() & ios_base::adjustfield) == ios_base::left ?
__str + __len :
__str,
__str + __len,
__os,
__os.fill()).failed())
__os.setstate(ios_base::badbit | ios_base::failbit);
and in locale
template <class _CharT, class _OutputIterator>
_LIBCPP_HIDDEN
_OutputIterator
__pad_and_output(_OutputIterator __s,
const _CharT* __ob, const _CharT* __op, const _CharT* __oe,
ios_base& __iob, _CharT __fl)
{
streamsize __sz = __oe - __ob;
streamsize __ns = __iob.width();
if (__ns > __sz)
__ns -= __sz;
else
__ns = 0;
for (;__ob < __op; ++__ob, ++__s)
*__s = *__ob;
for (; __ns; --__ns, ++__s)
*__s = __fl;
for (; __ob < __oe; ++__ob, ++__s)
*__s = *__ob;
__iob.width(0);
return __s;
}
Again I see no thread protection, but also this time the tools detect a hazard.
Are these real issues? For plain calls to operator<< the value of width doesn't change, and is always 0.
libstdc++ does not produce the error while libc++ does.
iostream.objects.overview Concurrent access to a synchronized ([ios.members.static]) standard iostream object's formatted and unformatted input ([istream]) and output ([ostream]) functions or a standard C stream by multiple threads does not result in a data race ([intro.multithread]).
So this looks like a libc++ bug to me.
I got the answer from Jonathan Wakely. Makes me feel rather stupid.
The difference is that on Fedora, libstdc++.so contains an explicit instantiation of the iostream classes. libstdc++.so isn't instrumented for ThreadSanitizer so it cannot detect any hazards related to it.

How to fix v8 deprecated GetFunction?

I'm trying to repair node-osmium so that it works with Node 12 as I've got some old code I'd like to run.
v8 has now fully deprecated a lot of APIs that do not signal failure properly. These were previously only warnings of deprecation soon, they're now errors so it will no longer build. I (think I've) fixed most of these by following this CPP STYLE GUIDE.md's use maybe version of v8 APIs section.
But, i'm stuck with this error for GetFunction:
../src/utils.hpp:39:67: error: no matching function for call to ‘v8::FunctionTemplate::GetFunction()’
Nan::MaybeLocal<v8::Object> maybe_local = Nan::NewInstance(Nan::New(T::constructor)->GetFunction(), 1, &ext);
I assume it's a similar fix as the other functions, but where do I get the context from in this constructor?
extract from node-osmium/src/utils.hpp:
namespace node_osmium {
template<class T>
auto unwrap(const v8::Local<v8::Object>& object) -> decltype(Nan::ObjectWrap::Unwrap<T>(object)->get()) {
return Nan::ObjectWrap::Unwrap<T>(object)->get();
}
template<class T, class... Args>
v8::Local<v8::Object> new_external(Args&&... args) {
Nan::EscapableHandleScope scope;
v8::Local<v8::Value> ext = Nan::New<v8::External>(new T(std::forward<Args>(args)...));
Nan::MaybeLocal<v8::Object> maybe_local = Nan::NewInstance(Nan::New(T::constructor)->GetFunction(context), 1, &ext);
if (maybe_local.IsEmpty()) Nan::ThrowError("Could not create new Buffer instance");
return scope.Escape(maybe_local.ToLocalChecked());
}
v8::Local<v8::Value> create_js_box(const osmium::Box& box);
osmium::osm_entity_bits::type object_to_entity_bits(v8::Local<v8::Object> options);
} // namespace node_osmium

Pubnub library not compiling on Particle Photon

I am trying to publish a message using pubnub on the Particle Photon. The code snippet below comes straight out of the Pubnub example code.
The code will not compile, with the message from the compiler as follows:
PubNub/PubNub.h:87:47: error: expected class-name before '{' token
class PubSubClient: public PubNub_BASE_CLIENT {
^
PubNub/PubNub.h: In constructor 'PubSubClient::PubSubClient()':
PubNub/PubNub.h:23:28: error: class 'PubSubClient' does not have any field named 'WiFiClient'
#define PubNub_BASE_CLIENT WiFiClient
^
The code for this tiny project is as follows:
// This #include statement was automatically added by the Particle IDE.
#include "PubNub/PubNub.h"
char pubkey[] = "<key here>";
char subkey[] = "<key here>";
char channel[] = "Channel";
void setup() {
Serial.begin(9600);
Particle.publish("Serial set up");
PubNub.begin(pubkey, subkey);
}
void loop() {
TCPClient *client;
char msg[64] = "{\"photon\":\"on\"}";
client = PubNub.publish(channel, msg);
client->stop();
Delay (30000);
}
Has anyone had a similar problem, and if so, can you guide me as to how to fix this.
Thanks.
It looks like the library available in Build IDE was in an older version (0.0.1). Fixed, latest version (0.0.2) has been published.
To update library in your app you need to remove the PubNub library from your app in Apps drawer:
And then go to Libraries drawer, find PubNub library, click Include in App, select your app and confirm:

GoogleTest CMake doesn't recognize TEST_F: Like it's not recognizing GTest something

OK, I admit it, this is a unique case. When we build our application we are using make, so I've included my tests in a test folder under src. Then at the same level as our release folder we have created a unit-test folder that includes all of our source files and our test source files.
But my IDE is CLion, which uses CMake. In my CMakeLists.txt file, I have included:
enable_testing()
find_package(GTest REQUIRED)
include_directories(${GTEST_INCLUDE_DIRS})
add_executable(TestProject ${SOURCE_FILES})
target_link_libraries(TestProject ${GTEST_BOTH_LIBRARIES})
I am creating my first Test Fixture. Here is the code:
#include "OPProperties.h"
#include "gtest/gtest.h"
namespace {
// The fixture for testing class OPPropertiesTestTest.
class OPPropertiesTestTest : public ::testing::Test {
protected:
// You can remove any or all of the following functions if its body
// is empty.
OPPropertiesTestTest() {
// You can do set-up work for each test here.
}
virtual ~OPPropertiesTestTest() {
// You can do clean-up work that doesn't throw exceptions here.
}
// If the constructor and destructor are not enough for setting up
// and cleaning up each test, you can define the following methods:
virtual void SetUp() {
// Code here will be called immediately after the constructor (right
// before each test).
}
virtual void TearDown() {
// Code here will be called immediately after each test (right
// before the destructor).
}
// Objects declared here can be used by all tests in the test case for OPPropertiesTestTest.
};
TEST_F(OPPropertiesTestTest, ThisTestWillFail) {
EXPECT_EQ(0, 2);
}
} // namespace
int main(int argc, char **argv) {
::testing::InitGoogleTest(&argc, argv);
return RUN_ALL_TESTS();
}
Here is an image capture:
Notice the syntax checker errors in my TEST_F function. When I started to type TEST_F code completion is trying to find a Boost Test Function.
Can someone tell me what else I need to add to the CMakeLists.txt file or what I am not doing that GTest functions are not being recognized?
As πάντα ῥεῖ pointed out, I hadn't actually tried to build the code. When I did I first received a linker error for pthread, so we added the following line the the CMakeLists.txt file:
target_link_libraries(OnePrint pthread)
Then I tried again to build and received these errors:
/home/user/gtest-1.7.0/lib/.libs/libgtest.so: undefined reference to `pthread_key_create'
/home/user/gtest-1.7.0/lib/.libs/libgtest.so: undefined reference to `pthread_getspecific'
/home/user/gtest-1.7.0/lib/.libs/libgtest.so: undefined reference to `pthread_key_delete'
/home/user/gtest-1.7.0/lib/.libs/libgtest.so: undefined reference to `pthread_setspecific'
collect2: error: ld returned 1 exit status
So, I ran a search on these errors and found this question.
The answer that worked for me was here.

Error : Expected a declaration

I am writing a code in Visual C++ to access serial port.
Code is given below:-
#include<stdio.h>
#include<cstring>
#include<string.h>
#include<conio.h>
#include<iostream>
using namespace std;
//#include "stdafx.h"
#ifndef __CAPSTONE_CROSS_SERIAL_PORT__
#define __CAPSTONE_CROSS_SERIAL_PORT__
HANDLE hSerial= CreateFile(L"COM1", GENERIC_READ | GENERIC_WRITE,0,0,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0);
if(hSerial==INVALID_HANDLE_VALUE)
{
if(GetLastError()==ERROR_FILE_NOT_FOUND){
//serial port does not exist. Inform user.
}
//some other error occurred. Inform user.
}
In the above code I am getting error at if in line
if(hserial==INVALID_HANDLE_VALUE)
Error is given below:-
Error:expected a declaration
I am getting same error at both braces } at the end of if statement
I want to know why I am getting this error and how to resolve it
I think you may want to read this. The problem is you are trying to use an if statement at namespace scope (global namespace) where only a declaration is valid.
You will need to wrap your logic in a function of some kind.
void mySuperCoolFunction()
{
if(hSerial==INVALID_HANDLE_VALUE)
{
if(GetLastError()==ERROR_FILE_NOT_FOUND)
{
//serial port does not exist. Inform user.
}
//some other error occurred. Inform user.
}
}

Resources