We were porting some code to FreeBSD7 64...

1 view
Skip to first unread message

Mickey

unread,
May 21, 2010, 3:05:22 AM5/21/10
to nextgen_engg
This code is giving compilation error in 64 bit machine, but compiling
even without any warning on 32 bit machine. Why? How to fix it?

It has been fixed. I wanted to bring out the point how smart compilers
are and what unusual places a code can break across platforms.

machine01# uname -srm
FreeBSD 7.3-RELEASE amd64
machine01# cat test.c
#include <unistd.h>
int main(void)
{ ssize_t s;
int *i;
i = &s;
}
machine01# g++ test.c
test.c: In function 'int main()':
test.c:5: error: cannot convert 'ssize_t*' to 'int*' in assignment
machine01# g++ --version
g++ (GCC) 4.2.1 20070719 [FreeBSD]



machine02> uname -srm
FreeBSD 7.0-RELEASE i386
machine02> g++ test.c
machine02> g++ --version
g++ (GCC) 4.2.1 20070719 [FreeBSD]

Mickey

unread,
May 21, 2010, 3:11:17 AM5/21/10
to nextgen_engg
The actual issue was this:
There is a function that takes a pointer of type ssize_t. We were
passing to it the address of an int variable that is a member of a
class and which is heavily used.
prototype of function: void f(ssize_t*);
we were calling it like this: struct A { int i; }a; f(&(a.i));

we were neither allowed to change class A nor function f. And the code
was breaking on 64 bit Freebsd. We had to fix it.

Regards,
Jyoti

SUDHEER DURUSOJU

unread,
May 21, 2010, 2:23:17 PM5/21/10
to nextge...@googlegroups.com
I think word length of the machine is playing a role in generating compilation error. ssize_t and int might be getting different bytes allocated on 64 bit machine.

What is the result of sizeof(int) and sizeof(ssize_t) on 64-bit machine?

One non-preferred way of solving this is to type cast the pointer when calling it. Call the function like  f((ssize *)&(a.i)). This has the problem of accessing wrong portion of memory if the allocated sizes doesn't match

Other method is to use

typecast int ssize_t in main() so that ssize_t will be also represented as int. I am guessing this, did not tired it :)

-Sudheer

Mickey

unread,
May 24, 2010, 2:40:20 AM5/24/10
to nextgen_engg
On the 64-bit machine:
sizeof(int) = 4
sizeof(ssize_t) = 8

You already pointed out the drawback of casting int* into ssize_t* in
case ss-ze_t is larger.

ssize_t is declared in unistd.h or stddef.h so it wouldn't always be
possible to do it.

Given the constraints we had... we made a cheap fix... because we knew
what the code does (we knew that the calculation 'values' will fit in
an int):

ssize_t tmp = a.i;
f(&tmp);
a.i = (int) tmp;

:)

Regards,
Jyoti

On May 21, 11:23 pm, SUDHEER DURUSOJU <sdurus...@gmail.com> wrote:
> I think word length of the machine is playing a role in generating
> compilation error. ssize_t and int might be getting different bytes
> allocated on 64 bit machine.
>
> What is the result of sizeof(int) and sizeof(ssize_t) on 64-bit machine?
>
> One non-preferred way of solving this is to type cast the pointer when
> calling it. Call the function like  f((ssize *)&(a.i)). This has the problem
> of accessing wrong portion of memory if the allocated sizes doesn't match
>
> Other method is to use
>
> *typecast int ssize_t* in main() so that ssize_t will be also represented as
> int. I am guessing this, did not tired it :)
>
> -Sudheer
>
Reply all
Reply to author
Forward
0 new messages