Hi Xavi, On 2010 Feb 17, at 16:00, Xavi wrote:
> Hi Viktor, > >> even in the Windows API set. Dyn function engine >> should not pose extra limitation here. > > Well, I don't like limitations but in this case exist RAW type and I suppose > is appropriate for structures and arrays type TCHAR**, seems a bit redundant. > >> need extra translation modes, but simply switching >> encoded strings to nul terminated ones is not a >> complete solution. > > Maybe yes, I'm not sure, I just think that simplify use. IMO it's not simplification, it's just avoiding loss of information. In majority of cases you need to pass preallocated buffers to .c functions when you want to receive back values in these buffers. Usually you get back the length of such buffer in another parameter. If you're getting a length value, you can't assume that the buffer doesn't contain a zero char. Current behavior supports this case perfectly. When you're getting back strings as return value, they are usually zero terminated. Current implementation will return you a zero terminated string in this case, so it also matches the 'usual' case. Anyway it's very easy to create a function which discards the part of a string after the first leading zero (or cuts it to a given length), in case you need a zero terminated string. Current implementation makes this possible, but it doesn't cut off the case when you do need the rest of the data. We can implement such feature in the low-level engine, as an option. I've committed it to SVN. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
