dlt-user: fix invalid return in dlt_user_log_write_start_internal

[alexmohr]

dlt_user_log_write_start_internal might return OK when the buffer was not initialized, this can lead to other functions assuming that the buffer was setup correctly and thus access invalid memory.

The program was tested solely for our own use cases, which might differ from yours.
Licensed under Mozilla Public License Version 2.0

^{Alexander Mohr, alexander.m.mohr@mercedes-benz.com, Mercedes-Benz Tech Innovation GmbH, imprint}

[minminlittleshrimp]

Would it be meaning that the behavior of some scenarios when logging disabled should be by-passed here?
I believe there could be some reasons behind doing this.

[alexmohr]

Would it be meaning that the behavior of some scenarios when logging disabled should be by-passed here?

I didn't find such a thing but maybe I just missed it. But I'm not sure if it's a good idea to abuse it like this.
If we keep return OK here it should be clearly documented that log->buffer is only initialized when log->handle is not null. We had a crash because an application assumed that the buffer is set up when ok is returned and did not check log->handle.

Not yet having reasonable rca

[alexmohr]

Closing this as it has unintended side effects in dlt-qnx-system leading to breaking that service.

[minminlittleshrimp]

Hello @alexmohr
Could you kindly please go for a brief overview of the side effects?
I am dying to know the reason for closing this and the reason behind the abuse of the return value there.
Many thanks for considering my request.

[alexmohr]

Hi @minminlittleshrimp

so the actual crash that we had is due to an internal feature we're developing at the moment (which we will upstream eventually once its mature)
Anyways it contains the following lines of code.

 ret = dlt_user_log_write_start(&handle, &log, loglevel);
 if (ret < DLT_RETURN_OK)
 {
        return ret;
 }

The crash happened when dlt_user_log_write returned true when the buffer in fact was not initialized, so it was logical to me to introduce the change in this pull request.

In dlt-qnx-slogger2-adapter.cppsloggerinfo_callback::sloggerinfo_callback dlt_user_log_write_start is called as well.
If dlt_user_log_write_start returns DLT_RETURN_LOGGING_DISABLED we will exit the sloggerinfo_callback function with -1, which in turn will abort reading messages from the slog as it only continues as long as no error is returned in the callback and therefore dlt-qnx-system stops and no further slogs are read.

It's just a bit confusing that DLT_RETURN_OK means below threshold (there is even a comment in dlt_qnx_system) and DLT_RETURN_TRUE means that the log level is okay and the buffer is set up.