Re: svn commit: r16952 - branches/1.3.x

[David James <ja...@gmail.com>]

On 10/24/05, jerenkrantz@tigris.org <je...@tigris.org> wrote:
>     * r16920, r16923, r16950
>       Define typemaps for APR datatypes in all SWIG bindings.
>      Justification:
>        Fixes check-swig-pl on 64 bit platforms.
>        Fixes check-swig-rb.
>      Depends: r16903
>       Votes:
>         +1: djames
>         +1: kou (r16923 only)
> +       +0: jerenkrantz (too hacky; need a more portable solution)
Thanks for your review, Justin! With my +1 and your +0, this change is approved.

Our current typemaps work on standard 32-bit and 64-bit platforms,
because char, short, and int normally have standard sizes. Subversion
developers, do you have any ideas how to implement the APR typemaps in
a more portable way? In future, I'm hoping to rewrite our SWIG
typemaps for APR datatypes to work without making assumptions about
type sizes.

Here's what we have now.

+%apply unsigned char { apr_byte_t }
+%apply short { apr_int16_t }
+%apply unsigned short { apr_uint16_t }
+%apply int { apr_int32_t }
+%apply unsigned int { apr_uint32_t }
+%apply unsigned long { apr_size_t }
+%apply signed long { apr_ssize_t }
+%apply long long { apr_int64_t }
+%apply unsigned long long { apr_uint64_t }
+
+%apply unsigned int *OUTPUT { apr_uint32_t * }
+%apply unsigned long *OUTPUT { apr_size_t * }
+
+/* We assume here that apr_off_t is no bigger than a 64-bit integer.
+ * In some cases, apr_off_t might be as big as 128-bits. In those cases,
+ * we'll simply truncate apr_off_t to a 64-bit integer.
+ */
+
+%typemap(perl5, in) apr_off_t {
+  $1 = (apr_off_t) strtoll(SvPV($input, PL_na), 0, 0);
+}
+
+%typemap(python, in) apr_off_t {
+  $1 = (apr_off_t) PyLong_AsLongLong($input);
+}
+
+%typemap(ruby, in) apr_off_t {
+  $1 = (apr_off_t) NUM2LL($input);
+}




--
David James -- http://www.cs.toronto.edu/~james

Re: svn commit: r16952 - branches/1.3.x

[Branko Čibej <br...@xbc.nu>]

Alan Barrett wrote:

>On Mon, 24 Oct 2005, David James wrote:
>  
>
>>Our current typemaps work on standard 32-bit and 64-bit platforms,
>>because char, short, and int normally have standard sizes. Subversion
>>developers, do you have any ideas how to implement the APR typemaps in
>>a more portable way?
>>
The same way APR does -- with config-foo.

>> In future, I'm hoping to rewrite our SWIG
>>typemaps for APR datatypes to work without making assumptions about
>>type sizes.
>>    
>>
>
>I am new to subversion, and probably don't understand the issues, but
>why can't we use [u]int_{8,16,32,64}_t as defined in <stdint.h> on many
>platforms, and as standardised in C99?  It is presumably possible to
>write some autoconf magic to define those types for platforms that have
>a missing or broken or pre-C99 version of <stdint.h>.
>  
>
Our baseline is C90 (or 89 for the ANSI-centric), which means we can't 
rely on stdint.h. That in turn means we have to rely on configury magic 
anyway, it's easier to just typdef apr-like names on all platforms.

-- Brane


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r16952 - branches/1.3.x

[Alan Barrett <ap...@cequrux.com>]

On Mon, 24 Oct 2005, David James wrote:
> Our current typemaps work on standard 32-bit and 64-bit platforms,
> because char, short, and int normally have standard sizes. Subversion
> developers, do you have any ideas how to implement the APR typemaps in
> a more portable way? In future, I'm hoping to rewrite our SWIG
> typemaps for APR datatypes to work without making assumptions about
> type sizes.

I am new to subversion, and probably don't understand the issues, but
why can't we use [u]int_{8,16,32,64}_t as defined in <stdint.h> on many
platforms, and as standardised in C99?  It is presumably possible to
write some autoconf magic to define those types for platforms that have
a missing or broken or pre-C99 version of <stdint.h>.

--apb (Alan Barrett)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org