C++ client can access csv direct, but presented by PHP causes stack corruption of cha

John_McGlaughli

[FONT="Courier New"]
file.csv
|
|
|
|
------------> Client
If the client accesses csv file direct as URL
data is interpreted by dll without error

file.csv
|
|
PHP SITE
|
| There is NO html formatting. The response must be strictly data, 1 line only.
|
------------> Client
Causes stack corruption at client of
char array doing strcat of line from Web object
[/FONT]

I have a third party api that i need to get data from an external server. I don't want to write custom tcpip code for communications, html is a perfect cheap solution.

I can access the csv file directly from the server as a URL without incident, but need to perform different services for the client based on the request. Access to the csv file is only one such request, there are control features that must be performed.

If the PHP script reads and echos the contents of the csv file to the client a stack corruption occurs on the communications dll.

I don't have access to debugging tools for the dll, the only conclusion I can think of is that the PHP script is not NULL terminating the character string when echoing the response to the client and the 1024-1 byte char array buffer is being overrun.

The csv file has 20 elements at less than 150 bytes total.

If any one can please point me in the right direction I would be most appreciative.

for now I have a less than desirable workaround which limits my control path to integer responses and csv file access directly from URL. This requires me to creat additional csv files for control data to be passed out of band rather than in band to the client request.

Thanks in advance
John McGlaughlin

johanafm

PHP strings are not null terminated, and as I've understood things, string length is an internal property of the string. But you could of course ascertain that you send a terminating null character and while you're at it also that the string is not more than the buffer can deal with.

$string = input_data();
/* Limit length
	if dealing with multibyte strings, substr can obviously cut off the last
	charcter "in the middle", but the good thing is that substr operates on bytes
	so you really do get 1023 bytes */	
$string = substr($string, 0, 1023);

# append your null character
$string .= "\0";

But if you have access to the C code, you really should protect yourself by inspecting the last byte of received data and add \0 if needed. Or initialize your entire buffer with \0 before each time you read data into it, and never read more than 1023 characters from the input stream.

John_McGlaughli

Adding the null char was my conclusion as well.
Unfortunately that does not seem to be the solution
I incorporated your addition

$fh = fopen($filename,"r");
if ($fh) {
  $EAdata = fread($fh, filesize($filename));
  fclose($fh);
  $len = strlen($EAdata)+1;
  $EAdata = substr($EAdata, 0, $len);
  echo($EAdata . "\0");
} else {
  echo(NO_PICK);
}

Alas, this was not the problem
A darn typo in the $_GET arguments returned null so I was sending an empty string back to the client.

The \0 did not help or I was tired or both.

But now I have fail safe on the script and in the dll.

And a corrected TYPO.

This is why there is a 10 lines of code average per day.