3 Replies Latest reply on Oct 30, 2019 3:50 AM by PriyaM_16

    int32_t typedef conflict


      I am porting some code to 43xxx_Wi-Fi project.

      In the code being ported following lines are present.

      typedef float float32_t;

      typedef double float64_t;

      typedef bool bool_t;

      typedef char char_t;

      typedef unsigned char uint8_t;

      typedef signed char int8_t;

      typedef unsigned int uint32_t;

      typedef unsigned short uint16_t;

      typedef signed short int16_t;

      typedef signed int int32_t;

      typedef unsigned long long  uint64_t;

      typedef signed long long  int64_t;


      In  one of the files (tools/ARM_GNU/include/stdint.h)  below lines are present.

      typedef signed long int32_t;

      typedef unsigned long uint32_t;


      compiler is throwing error because of conflicting typdefs of int32_t and uint32_t.


      I think there would be some option to config stdint.h file so that all data types matches with code being ported.

      Any help in this regard is commendable

        • 1. Re: int32_t typedef conflict


          Can you change the ported lib to use the definitio as per WICED?

          The standard library stdint.h is included in lot of files and it will result in conflict with yourported lib.

          • 2. Re: int32_t typedef conflict

            That is what i have done now.

            But because of this change i am getting some other compilation issues in ported lib.

            For example:

            there is a function declaration in third party stack as below

            int fn_name()

            and function definition is in some other file as below

            int32_t fn_name()


            //function body


            as per stdint.h int32_t  is signed long

            means function definition looks as below

            signed long fn_name()


            //function body


            function declaration and function definition prototype is not matching leading to compilation error.

            I am not supposed to change third party stack (so that i can upgrade blindly to latest available version)

            I understand that this type of errors come as third party stack has not followed standard convention for datatypes.

            and i am sure that this is not something new.

            I didn't got any good answer after googling.

            so posted question here with the hope of getting practically implementable solution.

            • 3. Re: int32_t typedef conflict

              You can remove the functions that are not used by protecting them under macros.