pnoltes commented on code in PR #782:
URL: https://github.com/apache/celix/pull/782#discussion_r1922700975
##########
libs/dfi/README.md:
##########
@@ -71,9 +71,9 @@ The data types supported by the interface description include:
*Type schema*:
- |**Identifier**|B |D |F |I |J |S |V |Z
|b | i | j | s |P | t |N |
-
|---------|---|------|-----|-------|-------|-------|----|--------------|-----|--------|--------|--------|------|------------------|---|
-
|**Types**|char|double|float|int32_t|int64_t|int16_t|void|boolean(uint8)|uchar|uint32_t|uint64_t|uint16_t|void
*| char *(C string) |int|
+ |**Identifier**|B |D |F |I |J |S |V |Z
|b | i | j | s |P | t |N | p
| a |
Review Comment:
A `a` with annotations sound good.
IMO there is a different between local calls and remote calls. Generally
speaking local calls can be trusted (although here is also room for improvement
(static bundles / signed bundles, because you can dynamically install new
bundles). A remote call is less trustworthy, so IMO crashing (assert fail) is
then not an option.
To be honest, I am still unsure if the current array list implementation is
the correct approach. Another option could be to really split up the public
array list API in a long, double, string, pointer, boolean, version array. So
something like: `celix_long_array_list_t` with functions like
`celix_longArrayList_get`, etc.
The underlying code can still be the current array_list, but the public api
only provided wrapper around the generic impl.
If we want to do that, this can and should be done separate from this pull
request.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@celix.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
