FindPattern and 64 bit

[Wolfgang]

Hm, as nobody is addressing my 32 - 64 bit issues, I'll keep wondering:

The function FindPattern seems not suitable for 64 bit, because the starting index still expects a regular 'int'. The 'number of bytes' is defined as ssize_t, but this seems not very consistent if I may start within the first 16 bit, but then extend to 65 bit length; it's strange that it's not possible to start at a length of 2^35 and search for 2 bytes only...

Moreover, the help of argument 'number of bytes' says: The function returns an error if you pass a value greater than UINT_MAX.

On a 64 bit system, using, as required, ssize_t, UINT_MAX is a very small number...??

Either I completely misunderstood the idea of ssize_t, or there are a couple of bugs in the implementation of 32 bit / 64 bit functions.

[Wolfgang]

The same is true for the function CopyString: target and source index are of type 'int', while the function strlen returns a value of size_t.

As a result, using the function CopyString (,,strlen(),,) returns a compiler warning 'Conversion from 'size_t' to 'int' might lose data'.

As said, I agree with the compiler warning, but I do not fully understand the reasons why similar function arguments are defined so differently.

[Mert_A. · Accepted solution]

The set of "String Manipulation" functions to which both FindPattern and CopyString belong don't support strings longer than INT_MAX bytes. Note that StringLength (which is this set of functions' eqivalent of strlen) returns an int. These functions were not modified to support longer strings, because it was not expected that a program would need to work with strings greater than 65,535 bytes in length. This conservative approach was taken to avoid unnecessary warnings when porting 32-bit code to compile in 64-bit mode. Consider the following line:

int len = StringLength(str);

When compiled in 64-bit mode, this line generates no new warnings. If StringLength had been modified to return an ssize_t, there would have been a new compiler warning about possible truncation of the value (just as you saw when passing strlen() into CopyString).

If you are working with generic memory, rather than true strings, you're probably better off using the ANSI functions (e.g. memcpy, strlen, etc).

Mert A.

National Instruments

Message Edited by Mert A. on 04-01-2010 04:25 PM

[Mert_A.]

Whoops. Meant to put 2,147,483,647 as the maximum string length... April Fools?

Mert A.

National Instruments

[LuisG]

One other point to add to Mert's explanation. One reason why some of those string functions were modified to take size_t or ssize_t (for input parameters only), even though they don't really support large buffers, is because users might be passing a sizeof expression as the value for those parameters.

For example:

 

char buffer[] = "test string";

FindPattern (buffer, index, sizeof (buffer) - 1, "xyz", 0,  0);

This code works just fine in 32-bit. But in 64-bit, because sizeof () results in a size_t expression, you would get a warning if you tried to compile that code and the function expected an int parameter. In order to avoid that warning, a lot of functions that accept buffer lengths were modified to take size_t instead. FindPattern takes a ssize_t, not size_t, because you have to be able to pass -1 as the length. But either one avoids the warning.

Luis

[Wolfgang]

Hi Mert,

Thanks! This means that converting current 32 bit programs to 64 bit aware versions one should replace the function strlen by StringLength.

This is fine with me (actually I wasn't aware of this funcion because strlen does the same job - whith a different type declaration).

Enjoy the holidays, Wolfgang

[Mert_A.]

Well, that's not really true in general. By no means do we expect that everyone who wants to build 64-bit binaries from their code should replace their calls to strlen with StringLength... just you. 😉 Basically, if your code is using the String Manipulation functions in the Formatting and IO Library (like CopyBytes, FindPattern, CopyString, etc), using StringLength instead of strlen may avoid some warnings.

Happy holiday weekend to you too.

Mert A.

National Instruments

[Wolfgang]

Hi Mert,

It is not just me... it will affect everyone who cares about compiler warnings, and who happens to use the NI formatting library (FindPattern...) with the (typical) need to use the length of a string somewhere in these function calls.

My point is: the advice 'you may ignore the compiler warnings' is not a good advice...

Anyway, you pointed me to a simple solution, and the 'Replace' function of the editor will do all the work, so it's o.k. for me

[LuisG]

Wolfgang,

Mert is out of the office this week, so I'll reply for him.

I think you misunderstood his point. He wasn't saying that you should simply ignore warnings. What he was saying was that, depending on what other functions you are also using, it might be better to use StringLength instead of strlen. He said that doing that might make it easier to avoid warnings. But in either case, you should certainly try to avoid the warnings.

Although none of these functions support strings that are greater than 2^32 (if such a string did exist, you certainly wouldn't want to call strlen on it, or you'd be waiting all day for it to return...) functions such as strlen nevertheless use size_t for the return value, since they're required to do so by the ANSI C specification. Therefore, if, for example, you're storing the return value of strlen in an int variable, or you're passing it to another function that takes an int parameter, you will see a warning in a 64-bit build, unless you cast it to an int first (which is also a perfectly acceptable way of eliminating such a warning). What Mert was saying is that if you use StringLength instead, you won't have to use the cast, since that function already returns an int instead of a size_t.

Luis