Lists with no keys are described in ConfD user guide - “Operational data lists without keys”.
There actually is a hidden key, and you should return some value (artificial number) instead of NULL in your get_next() response.
Then you can implement get_object() in usual way… (or you can go directly with get_next_object() to save an extra IPC communication of separate get_next()/get_object() invocations)
True, but if @aruns17 actually has, and wants to have, a container, in current versions of ConfD the CONFD_DAEMON_FLAG_BULK_GET_CONTAINER can be passed to confd_set_daemon_flags() to indicate that the data provider is prepared to handle get_object() for a container in certain cases, as described in the confd_lib_dp(3) man page.
Well, in the current implementation, even if your daemon uses the CONFD_DAEMON_FLAG_BULK_GET_CONTAINER flag, it actually has no effect if get_object() isn’t implemented. But there is no point in using the flag if you don’t implement get_object(), and the documentation says “This flag tells ConfD that the data provider is prepared to handle a get_object() callback invocation for…”
Hm, but maybe I misunderstood your question about “get_object() is not implemented for a container”. From ConfD’s point of view, you implement get_object() - or not - for a callpoint. I.e. if you have implemented get_object() for a given callpoint, and used the flag, and the callpoint covers leafs that are candidates for get_object()-for-container invocation as described in the man page, get_object() may be invoked for the container, even if the actual callback code can’t handle that. ConfD obviously has no way of knowing what your code can do - the point of the flag is to allow you to tell ConfD about it.