Thread: C++ Gurus, UNIX vs. Windows ascii problem perhaps?

Okay, I'm supposed to have their program run right on both the Unix platform and Windows platform. Now, it runs fine on both, but the output is wrong on Unix. Now, I'm guessing that maybe the ASCII values are different from OS, and that's possibly my problem. Can anyone verify this?

Here's the output that I get from Windows:

Search string: the
The string to search for is the
The string size is 3
Line Number
------------
1 1
2 0
3 1
4 0
5 1
6 0
7 1
8 0
9 1
10 0
11 0
12 0
13 1
14 0
15 2
16 0
17 0

And here's the output I get from Unix:

Search string: the
The string to search for is the
The string size is 4
Line Number
------------
1 0
2 0
3 0
4 0
5 0
6 0
7 0
8 0
9 0
10 0
11 0
12 0
13 0
14 0
15 0
16 0
17 0

And here's my code:

Code:

#include <iostream.h>
#include <fstream.h>

const int  LINESIZE = 45;

int  TextEqual (char target[], char lineInput[], int stringNum, int stringSize);
void ConvertLower(char target[], int size);

int main()
{
	char	 userInput[LINESIZE];
	char	 lineInput[LINESIZE];
	ifstream inFile;
	int		 lineCounter = 1;		// holds count of what line it's on
	int		 stringNum = 0;			// holds count of string finds per line
	int		 stringSize = 0;

	inFile.open("EULA.txt");

	// get string to search for and convert to lower case
	// get number of characters in string
	cout << "Search string: ";
	cin >> userInput;	
	ConvertLower(userInput, 45);
	for (int counter = 0; counter < LINESIZE; counter++)
		if ((userInput[counter] >= 97) && (userInput[counter] <= 122))
			stringSize++;

	cout << "The string to search for is " << userInput << endl;
	cout << "The string size is " << stringSize << endl;

	// print out heading
	cout << "Line\tNumber" << endl;
	cout << "------------" << endl;

	while (inFile.peek() != EOF)
	{
		// get new line of data
		inFile.getline(lineInput, 50, '\n');
		ConvertLower(lineInput, 45);
		
		// prints line number and number of string finds		
		
		stringNum = TextEqual(userInput, lineInput, stringNum, stringSize);
		cout << lineCounter << '\t' << stringNum << endl;


		// increase the line position and set the number
		// of string finds to 0
		stringNum = 0;
		lineCounter++;
	}
	
	inFile.close();

	return 0;
}

int TextEqual(char target[], char lineInput[], int stringNum, int stringSize)
{
	int numCorrect = 0;

	for (int position = 0; position < LINESIZE; position++)
	{	
		if (lineInput[position] == target[numCorrect])
			numCorrect++;
		else
			numCorrect = 0;

		if (numCorrect == stringSize)
		{	
			numCorrect = 0;
			stringNum++;
		}	
	}

	return stringNum;
}

void ConvertLower(char target[], int size)
{
	for (int spot = 0; spot < size; spot++)
		if ((target[spot] >= 65) && (target[spot] <= 90))
			target[spot] = target[spot] + 32;
}

It's a very easy program, I'm just not sure about the differences from Unix to Windows, and vice versa. My problem is that Unix is saying the string is of length 4, but Windows says the string is of length 3. I used my own little for loop to determine how many characters are in the string based on their respective ASCII values. The TextEqual function relies on the size of the user inputted string. Any help?

Thanks,
-Steve

Originally posted by xds4lx
Its the way the text file is stored under Unix that is the problem, try opening the text file in vi and you will see a ^M at the end of the lines its because the text is stored different. If you uploaded the text file using ftp make sure you set it to transer in ASCII mode and not binary mode.

Hey mate, thanks for the help. I'm going to give this a try when I get off of work.

Thanks!
-Steve

Originally posted by Hammer
To expand:

Unix uses bytes of value 0x0a to denote the end of a line. This is a line feed character.

Windows uses bytes 0x0d 0x0a to denote end of line, this is carriage return / line feed. They have to be next to each other, in that order.

If you create a file on one system, then transfer it to the other system using a binary mode FTP, the EOL markers are not converted and you start having trouble recognising them on the second system. When you use ASCII mode transfer, the EOLs are converted from the native format to that of the receiving system.

Good stuff to know.

BTW, the problem I'm having is with the input from the user not from the file itself. The method that I used to upload the file already uses ASCII mode transfer.

The problem is that Unix is saying the is stored as 4 characters, and Windows is saying it's three. Three is the right amount. Any idea why its saying there is one extra than what it is supposed to? This is for a string thats inputted from the user, not from the input file.

-Steve

The strlen() function worked great! I couldn't remember which header file had a function that returned the length of an array.

-Steve

P.S. The edits to the program you made allowed the length to process correctly, however, there are now issues with the number of lines. I'll work that out. But right now, my program works fine on both Unix and Windows. Thanks for the cstring suggestion 'bro.