You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following discussion with Franck, we should deprecate enqueueing of a message parameter as a pointer to this parameter. Even though it can work when the parameter is allocated in the heap (e.g. the ThingML String type is generated as char*) and things are run on the same machine.
Moreover, ports and messages are concepts which may be used to communicate between things on different machines; thus, a pointer does not make sense.
In addition, please consider the following erroneous example in ThingML:
thing fragment Messages {
message send_bytes(mbytes : Byte[32]);
}
thing Sender includes Messages {
....
state SBytes {
on entry do
var data : Byte[32]
data[0] = '0'
data[1] = '1'
datasender!send_bytes(data)
end
....
}
vassik
changed the title
C/C++: parameters enqueueing as pointers should be depricated
C/C++: parameters enqueueing as pointers should be deprecated
Apr 28, 2014
Following discussion with Franck, we should deprecate enqueueing of a message parameter as a pointer to this parameter. Even though it can work when the parameter is allocated in the heap (e.g. the ThingML String type is generated as char*) and things are run on the same machine.
Moreover, ports and messages are concepts which may be used to communicate between things on different machines; thus, a pointer does not make sense.
In addition, please consider the following erroneous example in ThingML:
and generated code for the 'on entry' block in C
Since the message handling happens asynchronously, and we pass a pointer to a value (mbytes) on the stack, the pointer contents is changed.
The text was updated successfully, but these errors were encountered: