Works on Windows but not on HPUX, Help Please

[Smurff]

Hi,

This code works fine on win and linux but not on hpux. All is compiled
with gcc. Can anyone help please?

/*************** *************** *************** *************** *************** **/
/*
*/
/* encrypt
*/
/*
*/
/*************** *************** *************** *************** *************** **/
/* Description: Utility function that simply encrypts a string. Used
for */
/* simple password storage in the config file.
*/
/*
*/
/*************** *************** *************** *************** *************** **/
void encrypt(char str[],int key)
{
unsigned int i;
for(i=0;i<strle n(str);++i)
{
str[i] = str[i] - key;
}
}

/*************** *************** *************** *************** *************** **/
/*
*/
/* decrypt
*/
/*
*/
/*************** *************** *************** *************** *************** **/
/* Description: Utility function that simply decrypts a string. Used
for */
/* simple password storage in the config file.
*/
/*
*/
/*************** *************** *************** *************** *************** **/
void decrypt(char str[],int key)
{
unsigned int i;
for(i=0;i<strle n(str);++i)
{
str[i] = str[i] + key;
}
}
The decrypt function even shortens the length, which as you can see,
shouldnt happen and doesnt on other OSs

Any help would be great, thanks
Kind regards
Danny

[pete]

Walter Roberson wrote:

In article <44***********@ mindspring.com> ,
pete <pf*****@mindsp ring.com> wrote:

In article <11************ *********@i40g2 000cwc.googlegr oups.com>,
Smurff <da***********@ gmail.com> wrote:void encrypt(char str[],int key)
>{
> unsigned int i;
> for(i=0;i<strle n(str);++i)
> {
> str[i] = str[i] - key;
> }
>}

If the value of key is INT_MIN,
that would cause undefined behavior in encrypt.

Hmmm, do I read C89 correctly that the char str[i] will be
converted to an int, not an unsigned int, even if char is unsigned,
with the exception of the case where sizeof char == sizeof int
[that being the case where the value of an unsigned char might
not fit within a signed int] ?

Yes.
unsigned short can also be promoted to signed int.
Code which attempts to increment either unsigned short
or unsigned char until roll over,
without checking first to make sure that signed int
doesn't have the same number of value bits,
is undefined.
C89 3.2.1.1 Characters and Integers

Assuming that all values of char will fit within an int:

- if char is unsigned then its minimum value would be 0,
and if the value of key is INT_MIN then 0-INT_MIN could potentially
be INT_MAX+1 (2's complement system), but on 1's complement or
signed-magnitude then -INT_MIN is INT_MAX and no undefined behaviour
would have occured for those number systems

- if char is signed then its minimum value would be SCHAR_MIN
and that minus INT_MIN might exceed INT_MAX by abs(SCHAR_MIN)
or abs(SCHAR_MIN)+ 1 . But in this case, it would not just be the
key of value INT_MIN that leads to the undefined behaviour: it would
be any key between INT_MIN and INT_MIN-SCHAR_MIN that would lead
to arithmetic overflow on the subtraction.

On the other hand, once the subtraction is completed, the result
is being stored back into str[i] which is a char. If char is
signed then if the result of the subtraction is less than SCHAR_MIN
then the result of the store operation is undefined. If char
is unsigned then the result of the store operation *is* defined
no matter what the value of the subtraction was [unless the
subtraction result was undefined as per the above.]

In summary, if char is unsigned then there is undefined behaviour
in the case of key = INT_MIN on a 2s complement system, but no
undefined behaviour for 1s complement or signed magnitude;
The null terminator doesn't go through the loop in encrypt.
str[i] always has a non zero value in encrypt;
which is a positive value if char is unsigned.
If unsigned char gets promoted to signed int, as is likely,
and if key equals INT_MIN,
then the result of the subtraction will always excede INT_MAX,
regardless of 1s complement or signed magnitude.
if char is signed then there is a fair range of values of key
that will produce arithmetic overflow, and an even larger range of
values of key that will produce problems at the assignment operation
even if there was no arithmetic overflow.

--
pete