> I think native functions should be for general use only. > And I don't think MkXXX$() functions now represents good practice to be > used as now intended. > If your software runs on linux (what else?), you probably still need to > write these functions by your self > to correct endianess accordingly to sender/receiver architecture mismatch. > http://en.wikipedia.org/wiki/Endianness#Endianness_and_operating_systems_on > _architectures > > If we have problems to figure out proper usage for these functions, then I > don't think > they really have any general usage, and therefore Gambas should not have > native support for them. > > But I think there are at least two reasonable options... > > 1. Change behaviour of MkXXX$() functions to be more like conversion > functions, that has 'locked' endianess. > This is probably best option. > > Or 2., Kevin, maybe you should pick up MkXXX$() functions form current > Gambas source code for your own library. > > But of course this is all up to Benoit! > Regards, > Jussi >
I can't add an optional argument to these functions that would specify the endianness to use. *That* would be the best option. Either I find a way to implement that anyway, either I should remove them as you suggest. Actually if you want to be endianness aware, you must use a Stream (OPEN, MEMORY, PIPE,...). Stream handle endianness automatically with their ByteOrder property. Regards, -- Benoît Minisini ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Gambas-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gambas-user
