[lttng-dev] [RFC patch] [Babeltrace python bindings] Added missing call to _bt_ctf_get_decl_from_def in get_int_len(), and defined ssize_t

[Amit Margalit]

Hi,

(Separated patches with signed-off-by lines follow this email).

My description of the issue with ssize_t was lacking. In babeltrace.i.in 
we have the following declaration:

        ssize_t bt_ctf_get_int_len(const struct bt_declaration *field);

Since ssize_t is not defined elsewhere in babeltrace.i.in, SWIG (I am 
using swig-2.0.10) doesn't recognize it as an integer, and generates the 
following code in babeltrace_wrap.c:4710

  result = bt_ctf_get_int_len((struct bt_declaration const *)arg1);
  resultobj = SWIG_NewPointerObj((ssize_t *)memcpy((ssize_t 
*)malloc(sizeof(ssize_t)),&result,sizeof(ssize_t)), SWIGTYPE_p_ssize_t, 
SWIG_POINTER_OWN |  0 );
  return resultobj;

This is part of _wrap__bt_ctf_get_int_len().

When I compare this to a different function that needs to return an 
integer, I see _wrap__bt_ctf_get_array_len() for example, which has these 
lines:

  result = (int)bt_ctf_get_array_len((struct bt_declaration const *)arg1);
  resultobj = SWIG_From_int((int)(result));
  return resultobj;

This is what led me to define ssize_t as an unsigned long, which produced 
the correct result.

Perhaps different versions of SWIG behave differently, or perhaps still - 
the same version of SWIG when run on a different system behaves 
differently.

Thanks,

Amit Margalit
IBM XIV - Storage Reinvented
XIV-NAS Development Team
Tel. 03-689-7774
Fax. 03-689-7230



From:   Jérémie Galarneau <jeremie.galarneau at efficios.com>
To:     Amit Margalit/Israel/IBM at IBMIL
Cc:     "lttng-dev at lists.lttng.org" <lttng-dev at lists.lttng.org>
Date:   08/19/2013 06:10 PM
Subject:        Re: [lttng-dev] [RFC patch] [Babeltrace python bindings] 
Added missing call to _bt_ctf_get_decl_from_def in get_int_len(), and 
defined ssize_t
Sent by:        jeremie.galarneau at gmail.com



Inlining for review.
Please note that both patches in this series are missing your "signed-off 
by" line.

Also, the issues addressed in this patch are unrelated and should be fixed 
separately.

> From c3474a73eb137b2bb7984d3195094a263c024e65 Mon Sep 17 00:00:00 2001
> From: Amit Margalit <amitm at il.ibm.com>
> Date: Mon, 19 Aug 2013 14:08:40 +0300
> Subject: [PATCH 1/2] Added missing call to _bt_ctf_get_decl_from_def in
>  get_int_len(), and defined ssize_t
> 
> ---
>  bindings/python/babeltrace.i.in | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/bindings/python/babeltrace.i.in b/bindings/python/
babeltrace.i.in
> index dd2dacc..6c1f6fb 100644
> --- a/bindings/python/babeltrace.i.in
> +++ b/bindings/python/babeltrace.i.in
> @@ -53,6 +53,7 @@ trace to it."
>  typedef unsigned long long uint64_t;
>  typedef long long int64_t;
>  typedef int bt_intern_str;
> +typedef unsigned long ssize_t;

On which system is ssize_t undefined?
I'd personally use ptrdiff_t, but maybe it is undefined there too?

These typedefs should be handled at config time, is it something you would 
be interested in providing a patch for?

>  
>  /* =================================================================
>   CONTEXT.H, CONTEXT-INTERNAL.H
> @@ -866,7 +867,7 @@ class ctf:
>   Return the size, in bits, of an int or a negative
>   value on error.
>   """
> - return _bt_ctf_get_int_len(self._d)
> + return _bt_ctf_get_int_len(_bt_ctf_get_decl_from_def(self._d))

Good catch!

>  
>   def get_encoding(self):
>   """
> -- 
> 1.7.11.7
> 


On Mon, Aug 19, 2013 at 7:15 AM, Amit Margalit <AMITM at il.ibm.com> wrote:
In some systems, the system headers use ssize_t, which was not defined, 
causing get_int_len() to return a pointer to a python object instead of 
returning the integer. 
Also, the python code that called _bt_ctf_get_int_len() failed to wrap 
self._d with the call to _bt_ctf_get_decl_from_def. 

I'm attaching this patch to (hopefully) avoid line formatting issues. 




Amit Margalit 
IBM XIV - Storage Reinvented 
XIV-NAS Development Team 
Tel. 03-689-7774 
Fax. 03-689-7230
_______________________________________________
lttng-dev mailing list
lttng-dev at lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev




-- 
Jérémie Galarneau
EfficiOS Inc.
http://www.efficios.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20130820/03bf8c9c/attachment-0001.html>