We had some major headaches with this - mostly because legacy code written for 32bit architectures tends to make silly assumptions that pointers can be cast to integers. But there also a number of tricky cases where it wasn't immediately obvious that the datatype discrepancy was the root cause.
As it becomes harder to find 32bit desktop processors, this is going to become increasingly significant, especially for services or applications which communicate between the Neo1973 and a 64bit home/work PC. I noticed that the GIMP project has its own typedefs (guint, guint8, gint16, etc).. so I was wondering if OpenMoko will be supplying its own definitions too? Going into the future, it would mean that there is a level of protection against having to go back through reams and reams of code and finding obscure errors that could have been avoided very easily. On a more present-day note, if it had native conversions for big/small endianness, that would be really really nice, too. Richard _______________________________________________ OpenMoko community mailing list [email protected] http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
