generated code of enumeration type error(default uint8_t)

[dzvoid]

I use newest version of tool(v3.2.0.1) to generate code by .fidl file:
Using Franca Version 0.13.1.201807231814
and CommonAPI Version 3.2.0.v202012010850

In .fidl file, I define a enumeration :

enumeration TransforType {
    Message_TCP = 300
    Message_UDP = 400
}

The generated code:

struct TransforType : CommonAPI::Enumeration< uint8_t> {
    enum Literal : uint8_t {
        Message_TCP = 300,
        Message_UDP = 400
    };

I think default type uint8_t is wrong, it need uint32_t.

[dzvoid]

我自己解决了，测试没有问题。
例子：

1、fidl文件：

package enum
typeCollection CommonType {
    enumeration Net
    {
        TCP=300
        UDP=400
    }
}
interface InterfaceLocPos {
    version {major 0 minor 0}
    enumeration testEnum 
    {
        TEST_NONE = 1
        TEST_SINGLE = 1000
        TEST_DIFF = 2000
        TEST_FLOAT = 3000
        TEST_FIXED = 4000
        TEST_OTHER = 5000
    }
}

2、fdepl文件增加：

import "platform:/plugin/org.genivi.commonapi.someip/deployment/CommonAPI-4-SOMEIP_deployment_spec.fdepl"
import "platform:/plugin/org.genivi.commonapi.core/deployment/CommonAPI-4_deployment_spec.fdepl"
import "enum.fidl"
define org.genivi.commonapi.core.deployment for interface enum.InterfaceLocPos {
    enumeration testEnum {
        EnumBackingType = UInt32
    }
}
define org.genivi.commonapi.core.deployment for typeCollection enum.CommonType {
    enumeration Net {
        EnumBackingType = UInt32
    }
}

3、general代码：

${basepath}/bin/commonapi_core_generator/commonapi-core-generator-linux-x86_64 -d ${basepath}/../../../../third_party/src-gen/someip -sk ${basepath}/../fidl/enum/enum.fidl
${basepath}/bin/commonapi_someip_generator/commonapi-someip-generator-linux-x86_64 -d ${basepath}/../../../../third_party/src-gen/someip -ll verbose ${basepath}/../fidl/enum/enum.fdepl
${basepath}/bin/commonapi_core_generator/commonapi-core-generator-linux-x86_64 -d ${basepath}/../../../../third_party/src-gen/someip -sk ${basepath}/../fidl/enum/enum.fdepl

[kheaactua]

I seem to get the same result by simply running the core and someip generators with the deployment file. I'm using 3.2.14. So in your example, I would achieve the same by doing:

${basepath}/bin/commonapi_core_generator/commonapi-core-generator-linux-x86_64 -d ${basepath}/../../../../third_party/src-gen/someip -sk ${basepath}/../fidl/enum/enum.fdepl
${basepath}/bin/commonapi_someip_generator/commonapi-someip-generator-linux-x86_64 -d ${basepath}/../../../../third_party/src-gen/someip -ll verbose ${basepath}/../fidl/enum/enum.fdepl

[DKSH10]

Hello,
I am facing the same issue for commonapi-dbus-runtime . Below are the details.
Commonapi version:- 3.2.0
dbus:- 1.10.20

Issue:
Step 1: We have define enums as follows in the fidl file (types.fidl)

 ***/
enumeration ReturnValue_enum {
	NOK = -1
	OK    = 0
            INVALID = 260

}**

Step2: We faced the compilation error as overflow because the default backingtype for enum in 3.2.0 is uint8_t.
Step 3: Used deployment.fdepl to resolve the compilation issue (set default backend type to int32_t). The deployment.fdepl content is as below.

**import "CommonAPI-4_deployment_spec.fdepl"
import "types.fidl"

define org.genivi.commonapi.core.deployment for typeCollection example.abcd.Types {
enumeration ReturnValue_enum {
EnumBackingType = Int16
}
}**

Step 4: For the specific enum where the backend type is int16_t we see the signature i still as "y"(byte) where as the payload is 2 byte.This results in the disconnection of dbus with error as corrupted message. Below are the contents for the error.

Corrupted message stream, disconnecting
Disconnect transport.

Step 5 : Generate:

execute_process(COMMAND ..../commonapi-generator/commonapi-core-generator-linux-x86_64 -sk -d ${DEST_PATH}${fidl_name} ${FIDL_DIR}/${FIDL_PATH} ${FIDL_DIR}/deployment.fdepl RESULT_VARIABLE res)
execute_process(COMMAND ...../commonapi_dbus_generator/commonapi-dbus-generator-linux-x86_64 -dest ${DEST_PATH}${fidl_name} ${FIDL_DIR}/${FDEPL_PATH} RESULT_VARIABLE res)

Please suggest if something has been missed in the deployment.fdepl.

[kheaactua]

Hmm, I doubt it's the same cause, but it sounds a little related to COVESA/capicxx-someip-runtime#37 - though I only saw that issue after 3.2.0.

But this PR does point out a good place to check if your values are being deserialized properly in the someip runtime layer.

[DKSH10]

This issue we are facing in dbus runtime