celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <pepijnnol...@gmail.com>
Subject const pointers
Date Sun, 10 Jul 2016 11:15:58 GMT
Hi All,

The last days I worked on two issues introducing the usage of const
pointers to the celix API (CELIX-249 and CELIX-365).
The usage of const pointers where added because it gives a (IMO) cleaner
API, helps to prevent bugs, and makes it possible to use string defines
without casting.

To give an example the properties_get function now return a 'const char*'
instead of a 'char*'.
This means that the content of returned string cannot be modified without
casting to char* (which you should not do).
It is good to know that freeing a string also is not allowed (this is
considered modifying the content of the string).
By applying this change I already discovered some (dormant) bugs where the
return values of property_get where fed
to strtok_r (which modified the content of the string).

The big issues with these changes is that they are not backwards
compatible, which is also the reason why issue CELIX-249 was not picked up
Changing an input argument from 'char*' to 'const char*' is fine (you can
still feed it with 'char*'), but changing the return or output argument
from 'char*'/'char**' to 'const char*'/'const char**' is backwards
I took the liberty to apply these changes regardless, because were are
working on a major version increase for Celix (2.0.0) and as stated above
it has advantages.

Also for register/getting services, const pointers where added. I this case
I did _not_ change the API of bundleContext_getService,
service_factory->(un)getService and serviceRefernce_getService, because
this has IMO too much impact on existing code. Because the dependency
manager is fairly new I did change the service callback signatures of the
dependency manager and as result the examples using the dependency manager.

All in all the result is that most code using the development branch of
Celix needs some (small) changes to work with these updates.
Any thought/comments are welcome.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message