A couple of enum and type questions

[Sarvi Shanmugham]

1. I have an enum as follows

typedef enum my_thread_sched_mode_ {

    MY_THREAD_MODE_NORMAL = 0,

    MY_THREAD_MODE_NON_PREEMPTIVE = 0xffffffff,

} my_thread_sched_mode;

This generates code as

int _cffi_e_enum_my_thread_sched_mode_(char *out_error)

{

  if (MY_THREAD_MODE_NORMAL != 0) {

    snprintf(out_error, 255, "in enum %s: %s has the real value %d, not %d",

            "my_thread_sched_mode_", "MY_THREAD_MODE_NORMAL", (int)MY_THREAD_MODE_NORMAL, 0);

    return -1;

  }

  if (MY_THREAD_MODE_NON_PREEMPTIVE != 4294967295) {

    snprintf(out_error, 255, "in enum %s: %s has the real value %d, not %d",

            "my_thread_sched_mode_", "MY_THREAD_MODE_NON_PREEMPTIVE", (int)MY_THREAD_MODE_NON_PREEMPTIVE, 4294967295);

    return -1;

  }

  return 0;

}

The second snprintf causes a warning

__pycache__/_cffi__g644663dbx82c763c2.c:910: warning: this decimal constant is unsigned only in ISO C90

__pycache__/_cffi__g644663dbx82c763c2.c:912: warning: this decimal constant is unsigned only in ISO C90

__pycache__/_cffi__g644663dbx82c763c2.c:912: warning: format '%d' expects type 'int', but argument 7 has type 'long unsigned int'

__pycache__/_cffi__g644663dbx82c763c2.c:912: warning: format '%d' expects type 'int', but argument 7 has type 'long unsigned int'

        

I am guessing this is caused by the 0xffffffff

Is this a limitation of some sort, can it be eliminated.

2. There is warnings such as

__pycache__/_cffi__g644663dbx82c763c2.c: In function '_cffi_f_my_dm_execute':

__pycache__/_cffi__g644663dbx82c763c2.c:619: warning: passing argument 2 of 'my_dm_execute' from incompatible pointer type

for code generated as follows

int _cffi_f_my_dm_execute(struct my_dm_handle_*  x0, void(* x1)(struct my_dm_handle_* , long, uint64), long x2, uint64 *x3)

{

  return my_dm_execute(x0, x1, x2, *x3);

}

From cdef as follows

typedef void (*my_dm_exec_handler)(my_dm_handle xdm, intptr_t data,

                                    uint64 modifier);

int my_dm_execute(my_dm_handle xdm, my_dm_exec_handler h, intptr_t data,

           uint64 modifier);

I can see that this has something to do with the way intptr_t and uint64 is being translated/defined in the generated code 

and the way it is defined in the actual function definition in the library.

My question: What is the easy way to figure out what the right type should be. 

I have tried generating the myfile.E files with the macro expansion done, but doesn't seem to be helping. 

Any ideas.

sarvi 

[Sarvi Shanmugham]

For the second question relating to incompatible pointer time, here is what I see in .E file for one of .c files that gets compiled into the library

typedef unsigned int u_int64_t __attribute__ ((__mode__ (__DI__)));

.......

typedef u_int64_t uint64;

..........

# 126 "/nobackup/sarvi/mbs-ws2/nova/linkfarm/i686/usr/include/stdint.h" 3 4

typedef int intptr_t;

........

# 235 "./infra/mylib_share/include/my_dm.h"

typedef struct my_dm_handle_ * my_dm_handle;

.....

# 1156 "./infra/mylib_share/include/my_dm.h"

int my_dm_execute(my_dm_handle xdm, my_dm_exec_handler h, intptr_t data,

     uint64 modifier);

......

# 1226 "./infra/mylib_share/include/my_dm.h"

int my_dm_message_register(my_dm_handle xdm,

                            my_dm_exec_handler handler,

                            intptr_t context);

If I try to define ahead the following

typedef int intptr_t;

I get an error, i suspect because intptr_t is already defined by cffi itself.

cffi.api.CDefError: cannot parse "typedef int intptr_t;"

:18: Multiple type specifiers with a type tag

I have currently commented these functions out temporarily.

Based on

http://stackoverflow.com/questions/4559025/what-does-gcc-attribute-modexx-actually-do

And the fact that cffi predefines uint64_t to be 64 bits the following should work instead of the attribute/mode thing above.

typedef uint64_t u_int64_t;

How do I do I get this right and avoid the warnings? I am confused.

Sarvi

[Sarvi Shanmugham]

I finally settled with 

// My typedefs

typedef uint8_t u_int8_t;

typedef uint8_t u_int16_t;

typedef uint8_t u_int32_t;

typedef uint8_t u_int64_t;

// From the header mylib.h custom header file

typedef int8_t int8;

typedef int16_t int16;

typedef int32_t int32;

typedef int64_t int64;

typedef u_int8_t uint8;

typedef u_int16_t uint16;

typedef u_int32_t uint32;

typedef u_int64_t uint64;

based on the fact that cffi defines intN_t and uintN_t and the myib.E file uses the __attribute__((mode.... as in the below link

http://stackoverflow.com/questions/4559025/what-does-gcc-attribute-modexx-actually-do

I don't know what to do about intptr_t and size_t which according to mylib.E is defined as 

typedef unsigned int size_t;

typedef int intptr_t;

so have left it as is and commented out the API.

I am not sure if this is right

I still get the incompatible pointer time warning which I have not been able to eliminate.

Sarvi

[Armin Rigo]

Hi Sarvi,

On Fri, Sep 28, 2012 at 6:07 PM, Sarvi Shanmugham <sarv...@gmail.com> wrote:
> 1. I have an enum as follows
> typedef enum my_thread_sched_mode_ {
> MY_THREAD_MODE_NORMAL = 0,
> MY_THREAD_MODE_NON_PREEMPTIVE = 0xffffffff,
> } my_thread_sched_mode;

This is not standard C, because 0xffffffff does not fit an int. CFFI
enums are always ints for now. I added a check for the value to fit
in that range, and documentation about how to work around it if
needed.

> __pycache__/_cffi__g644663dbx82c763c2.c:619: warning: passing argument 2 of
> 'my_dm_execute' from incompatible pointer type

This is gcc being too precise. Indeed, types like 'intptr_t' are just
typedefs to the platform-specific built-in type of the correct size
--- int, or long, or sometimes long long. In your case it is 'long'.
Once CFFI has figured it out, it writes 'long' in the generated
source, which should be fully equivalent to 'intptr_t' --- except that
it occasionally produces this kind of warnings. FWIW we have the same
minor issue in PyPy, in the translation toolchain. Unsure how to
solve it. For now I'll open an issue.


A bientôt,

Armin.