expanding c code to be "more cross-platform"

[lvirden]

I'm responsible for supporting some C code which implements one time
passwords.

The author of the code is no longer available for help.

The code has been used for years on a sparc solaris platform.

However...

Now I need it to work on Linux Intel.

The behavior I am seeing is this.

I compiled this C code on Linux, using gcc, and it compiled without
complaint. I know that part of the code converts things into a hex
string from a long (and converts from the hex string into a long).

When I run a "build key" option of software using this code, it is
passed an IP address (for illustration, lets say"123.45.67.890").

A otp is generated.

Then, the command is issued with a flag that says "list the
information".
What it prints is
890.67.45.123

Now, what I am looking for are hints and tips on how to go about
generating things so that a command on either of the platforms will be
able to read and interpret correctly the information.

In other words, the data generated has to be readable across
platforms.

Are there some tutorials or guidelines for doing this sort of thing?

[Ben Bacarisse]

lvirden <lv*****@gmail.comwrites:

I'm responsible for supporting some C code which implements one time
passwords.

The code has been used for years on a sparc solaris platform.

However...

Now I need it to work on Linux Intel.

If at all possible, convert the code to portable C. You will then get
the same results on all machines. Where you can't, localise the
non-portable part into as few functions as possible and then re-write
these as required to get the desired behaviour.

It seems obvious, and I am sorry if I am telling you stuff you know,
but it is surprising how many people think that C is inherently
non-portable (especially if it is "doing stuff with bits").

If you can't post your code, can you say more about how the data is
manipulated? There is nothing in what you have said so far that
indicates any portability issues. With more information, we may be
able to suggest portable solutions, or at least point to the danger
areas.

--
Ben.

[lvirden]

On Jul 27, 12:33 pm, Ben Bacarisse <[e-mail]:

If you can't post your code,

I don't think I had better - can't violate certain contractual
agreements, etc.

can you say more about how the data is
manipulated? There is nothing in what you have said so far that
indicates any portability issues.

Well, there's a whole library of code here. But what I see is a setup
command which is passed several arguments, one of which is an unsigned
long IP address.
The ip address is passed, along with a variety of other arguments,
into an encoding routine. In the encoding routine, the ip address is
passed like this:

otp_uln2hex(&otp->ip, OTP_IP_BYTES, ptr);
ptr += OTP_IP_LEN;
*ptr++ = ' ';
*ptr++ = '0' + otp->sequence / 10000;
*ptr++ = '0' + (otp->sequence / 1000) % 10;
*ptr++ = '0' + (otp->sequence / 100) % 10;
*ptr++ = '0' + (otp->sequence / 10) % 10;
*ptr++ = '0' + otp->sequence % 10;
*ptr++ = ' ';

Where ptr is a pointer into a line. when all the processing is done,
there's one ascii line which is output to a file, which then other
processes read.

Inside the uln2hex routine, the pointer to an unsigned long, along
with a count and an output area is taken, and while the count is
greater than 0, the routine loops around a switch statement. The cases
are the bytes remaining.
For each byte, a line like this is executed:

case 1:
*ptr++ = hex[(*in >4) & 0xf];
*ptr++ = hex[*in & 0xf];

where hex[] is an array of hex ascii characters.

Does that help?

[lvirden]

On Jul 27, 12:58 pm, Roberto Waltman <[e-mail]:

If fixing your problem requires knowledge of the Solaris & Linux
platforms, (as opposed to generic C questions,) you may be better of
in a group dedicated to Solaris/Linux/networking.

I certainly wouldn't want to cause any problems, having read this
newsgroup off and on for many, many years.

Is there a group/mailing list/web forum dedicated to solaris/linux
networking issues where problems such as mine is more appropriate?

As for showing code. I wish I could. However, non-disclosure contracts
really keep me from showing the code.

[Keith Thompson]

lvirden <lv*****@gmail.comwrites:
[...]

Is there a group/mailing list/web forum dedicated to solaris/linux
networking issues where problems such as mine is more appropriate?

Probably comp.unix.programmer.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[lvirden]

On Jul 27, 6:59 pm, Ben Bacarisse <[e-mail]:

>

>
The only truly suspicious thing here is treating an IP address as an
unsigned long. That is not necessarily wrong, but it might be. I'd
be tempted to do a quick test: if you enter 1.2.3.4 as the address (on
Solaris) do you get the same encoding as you get when you enter
4.3.2.1 on the Linux implementation?

Okay, here's the weird thing. I put in 1.2.3.4 as an address to be
encoded, on Linux. I then, on Solaris, indicated that I wanted to
decode the value. It got the right information with no coding
problem. So it looks like my library is doing the right thing! Now I
have to back track to figure out where the information is being used -
because something definitely isn't using the encoded address
correctly.

Thanks for the ideas!

[CBFalconer]

lvirden wrote:

>
I'm responsible for supporting some C code which implements one time
passwords. The author of the code is no longer available for help.
The code has been used for years on a sparc solaris platform.

Now I need it to work on Linux Intel.

The behavior I am seeing is this.

I compiled this C code on Linux, using gcc, and it compiled without
complaint. I know that part of the code converts things into a hex
string from a long (and converts from the hex string into a long).

When I run a "build key" option of software using this code, it is
passed an IP address (for illustration, lets say "123.45.67.890").

A otp is generated.

Whatever that is. It has nothing to do with the problem.

>
Then, the command is issued with a flag that says "list the
information". What it prints is

890.67.45.123

Quite obviously you have run into something to do with endianism.
Somewhere you are treating the data as a sequence of bytes, rather
than as a long. In other words, invalid code, and it is biting. I
suspect you are also assuming 8 bit bytes, which may also bite in
the future.

You want to use an unsigned long to hold the value. Install things
with modulo 256 arithmetic and shifts, and extract things with
divisions by 256.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com