generated interface different between 32 and 64 bit platforms about gl-rs HOT 8 CLOSED

We could use libc::uintptr_t/libc::intptr_t instead of hardcoding
GLsizeiptr ourselves. It's just a typedef for i32/i64 but you can cast
to it and it will Just Work.

On Mon, Aug 25, 2014 at 4:00 AM, Cameron Hart [email protected]
wrote:

I've written some code that uses gl::BufferData. On Linux 64 bit the
buffer size parameter is i64 but on Windows 32 bit it's i32. It seems like
the size parameter should actually be int (or uint even) so that calling
code is portable between 32 and 64 bit architectures.

—
Reply to this email directly or view it on GitHub
#148.

http://octayn.net/

from gl-rs.

On further investigation this looks like a Rust issue. This is the relevant bug rust-lang/rust#11447. As detailed in the bug, I can work around it by casting to GLsizeiptr which ends up being the right size on 32 and 64 bit platforms. It's just a bit confusing because Rust's error message doesn't mention GLsizeiptr at all if you're using the wrong type, it will say i32 or i64 depending on platform which means the first thing you try is cast to i32 or i64 only to discover it breaks when you cross compile.

The code in question where I was having this problem looks like so:

gl::BufferData(gl::ELEMENT_ARRAY_BUFFER, index_data_size as GLsizeiptr, mem::transmute(index_data.as_ptr()), gl::STATIC_DRAW);

In my case index_data_size was a uint. The error I would get without the cast was "error: mismatched types: expected i64 but found uint (expected i64 but found uint)". Thus my confusion.

I guess this isn't a bug, it's more of a usability problem. You are probably best off sticking with Rust's ptrdiff_t for the same reasons they've stuck with it.

from gl-rs.

Sorry @cmr I didn't see your comment before replying. I found what seems like an acceptable work around to me, it might be nice if the Rust compile error was less misleading.

from gl-rs.

@cmr perhaps we need conditional compilation there?

from gl-rs.

It is currently set to c_int: https://github.com/bjz/gl-rs/blob/master/src/gl_generator/ty.rs#L262

from gl-rs.

c_int itself is conditionally defined, it's probably fine as long as you
cast to it. still annoying...

On Tue, Aug 26, 2014 at 9:53 AM, Brendan Zabarauskas <
[email protected]> wrote:

It is currently set to c_int:
https://github.com/bjz/gl-rs/blob/master/src/gl_generator/ty.rs#L262

—
Reply to this email directly or view it on GitHub
#148 (comment).

http://octayn.net/

from gl-rs.

Yeah, the issue is the error that mentions the base type, and not the alias. When I work with C APIs I always do as libc::c_foo, but I see plenty of PRs that instead cast to i32 etc....

from gl-rs.

Yeah. I think this is just a Rust bug. It "erases" the type definition too
soon for nice errors.

On Tue, Aug 26, 2014 at 10:17 AM, Brendan Zabarauskas <
[email protected]> wrote:

Yeah, the issue is the error that mentions the base type, and not the
alias.

—
Reply to this email directly or view it on GitHub
#148 (comment).

http://octayn.net/

from gl-rs.