LoadRunner, strlwr, strupr, Red Hat Linux, and you

[Rick Carter (University of Michigan)]

Hi all, more of passing on a discovery than a question, in case it saves someone else a couple of hours (I came to LoadRunner from a SysAdmin rather than a recent coding background, so speaking c as a second language).

Among other string-manipulation functions, LoadRunner supports two, strlwr and strupr (lowercase and uppercase a string, respectively). They work fine in VUGEN. However, our Load Generators are Red Hat Enterprise Linux, and my script with strlwr within fails there at "Error -- Unresolved symbol: strlwr".

As it turns out, this is not a standard c function (the rationale being it only works on US ASCII, essentially, and not, say, UTF-8 or any other character set). Therefore, I had to replace it with a roll-my-own, and not being the best "c" coder, I found that the one I found here seems to work fine as a replacement:

http://www.cprogramming.com/snippets/source-code/how-to-implement-strlwr-in-c

… with one minor change -- had to move "int i=0" to the top. Also, I discovered that anything with "str" followed by an alphabetic is reserved for c use, so I renamed it LocalStrlwr . It's working fine.

Hope this helps someone else,

- Rick Carter

--
Rick Carter
Application Systems Administrator Senior
Information and Technology Services
University of Michigan
rkca...@umich.edu
734-647-5941

[André Luyer]

Good to know that this is different between Windows (Vugen) and Linux. Thanks.

> "Error -- Unresolved symbol: strlwr".

On Windows the DLL containing these functions is already loaded when your script starts (thus the "symbol strlwr" _can_ be found/resolved dynamically). That's why it works in Vugen and load generators running on Windows.

> As it turns out, this is not a standard c function

Strlwr and strupr are part of the 'string' library, not a part of the core of C. Normally added (prototyped) using #include "string.h" -- not allowed in Vugen.

> (the rationale being it only works on US ASCII, essentially, and not, say, UTF-8...
Bad example. UTF-8 was designed for backward compatibility with ASCII and _can_ be processed by traditional null-terminated string functions ( http://en.wikipedia.org/wiki/UTF-8 ). But not for example UTF-16.

> had to move "int i=0"

That should be: had to remove.

> Also, I discovered that anything with "str" followed by an alphabetic is reserved for c use...
No problems here... I can create any str* function I like. The actual list of reserved words in C is quite small, see http://en.wikipedia.org/wiki/C_%28language%29#Keywords .

André

[Rick Carter (University of Michigan)]

On Dec 19,2013, at 2:12 PM, André Luyer <an...@luyer.nl> wrote:

Good to know that this is different between Windows (Vugen) and Linux. Thanks.

> "Error -- Unresolved symbol: strlwr".
On Windows the DLL containing these functions is already loaded when your script starts (thus the "symbol strlwr" _can_ be found/resolved dynamically). That's why it works in Vugen and load generators running on Windows.

> As it turns out, this is not a standard c function
Strlwr and strupr are part of the 'string' library, not a part of the core of C. Normally added (prototyped) using #include "string.h" -- not allowed in Vugen.

And on Red Hat Enterprise Linux Server release 6.4, they are not even included in string.h, nor anywhere else for that matter.

...

> Also, I discovered that anything with "str" followed by an alphabetic is reserved for c use...
No problems here... I can create any str* function I like. The actual list of reserved words in C is quite small, see http://en.wikipedia.org/wiki/C_%28language%29#Keywords .

True that one *can*. However, per, for instance https://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html, "Names beginning with 'str', 'mem', or 'wcs' followed by a lowercase letter are reserved for additional string and array functions."

Thanks for the extra info!

André

- Rick