For most I/O stream implementations the serial communication specific
functions are meaningless. Implementing them as no-ops allows the dive
computer backends the call the I/O stream functions unconditionally.
However, implementing the no-op with a dummy function returning
DC_STATUS_SUCCESS, does not only add some (small) overhead at runtime,
but also requires many such functions. This is inconvenient and the same
result can easily be obtained by using a NULL pointer instead.
The consequence is that the logic is reversed now. To obtain the
previous behaviour of returning the DC_STATUS_UNSUPPORTED error code
again, you'll need to implement a dummy function. But that's fine
because it's the less common case.
For the socket based I/O stream implementations (IrDA and bluetooth) the
serial communication specific functions are meaningless. Implementing
them as no-ops allows the dive computer backends the call the I/O stream
functions unconditionally.
This is important for the bluetooth implementation, because bluetooth
enabled dive computers will be able to use both the native bluetooth
communication and the legacy bluetooth serial port emulation.