printf problem

[cyreon]

Now I'm not sure if anyone else has ever run in to a problem such as this, however, I would like to show you the code and an example of the output for that section of code to see if it's a possibility, at least it's something that I have never personally run in to before now...

else if( !strcmp(buff, "MODE") ) {
	strGet(buf, " ", 3, buff);
	strGet(buf, " ", 4, btmp);
	strRem(btmp, ":", 1);
	printf("From: %s\n", From);
	printf("Mode: %s\n", btmp);
	printf("On: %s\n", buff);

	if( !strcmp(From, buff) ) {
		sprintf(buff, "%s sets %s on themself.", From, btmp);
//		fprintf(stdout, "%s sets mode %s on themself.\n", From, btmp);
		printf("%s\n", buff);
	}
	else {
		sprintf(buff, "%s sets mode %s on %s.", From, btmp, buff);
		printf("%s\n", buff);
	}

	// TODO: store mode information as appropriate
	return(0);
}

A sample output:

From: Bot
Mode: +x
On: Bot
    on themself.

For some reason all of the variables produce the proper values, but the printf() statements in the control statements are not displaying the entire message. Does anyone have a reason as to why this could be happening? I have verified also that the strGet() and strRem() calls are doing exactly as they should be (with the first printf() statements) and so this is not the reason.

Thanks in advance for any assistance.

[swoopy]

How is buff declared?

[gibsosmat]

    strGet(buf, " ", 4, btmp);
    strRem(btmp, ":", 1);

what are these?

buff, buf;

good way to save time from typing long variable names.. but make sure that you wont revisit your code again

[matsp]

Looks to me like "Btmp" has a newline on the end.

--
Mats

[cyreon]

For swoopy and gibsosmat:

the variables are declared as follows:

char *buf; // variable coming in on function call - holds raw network data coming in from server
char *buff[2049]; // general blank buffer used to put a network string together before sending out, or using it to simply grab sections of raw data that was received

Now here are the following prototypes:

// NOTE: I have tested the following functions in all aspects of their use and they do work
//            This is also seen by the original post output where the first three printf() calls display,
//            the information that these functions would have been used to grab.
//
// removes the nth(int) item of 'const char *' from 'char *'
int strRem(char *, const char *, int);
// gets the nth(int) item from 'const char *'(first), separated by 'const char *'(second) and
// places it in 'char *'
int strGet(const char *, const char *, int, char *);

matsp:
I have verified that there is no new line character by essentially doing - btmp[(int)strlen(btmp)-1]='\0' - this is performed in the strGet() function. To me though, this does not explain why sections of the printf() call (the final ones) do not display all of their text. The output should be (%s)Bot sets (%s)+x on themself., however, the output that I get is on themself. So why is it that the "sets" part of the string just doens't display? This factor, even with a new line in one of the strings, doesn't make any sense to me. Would the new line character not just cause the current line to change on the screen by forcing it to go to the next, so the output should simply then be spread across multiple lines instead of entire sections missing. Also as a note, each line is ended with a CRLF pair (compensated for by the function reading the raw data from the connection), so even if my "compensation" code isn't working up to par, then it would simply be one of these getting through.

Hope this is all of the information that you guys needed, if there is anything else... just let me know. I want to figure this one out, it's not a dire need in order for the program to run since it's just output on a screen and the main code does infact work, but I would like to figure this one out because I have never seen output like this before with just using a printf() call.

[matsp]

Try printing the strings involved as hex-numberes, eg:

#define printHex(s) doPrintHex(#s, s)
void doPrintHex(const char *name, const char *s)
{
    int len = strlen(s);
    int i;
    printf("string %s: \n+++\n", name);
    for(i = 0; i < len; i++) {
        printf("%02x ", s[i]);
    }
    printf("\n***\n");
}

char myVar = "Hi!\n";
printHex(myVar);

This would output:

string myVar:
+++
48 69 21 0a
***

--
Mats

[cyreon]

Thanks matsp. Turns out that btmp had something going on (not sure exactly what it was just yet... still trying to locate what character 0d is). It was stored at the end, causing odd abnormalities in the output (such as missing characters in the string, or even going as far as to take a period I had at the end of some output and replacing the first character in the output with it... I really don't know any character that can cause such a problem... until now).

[matsp]

0d is "carriage return" (CR). You are possibly reading a string from a file without the CR/LF->LF conversion, e.g. opening the file in binary, usign fread() or some other non-converting way to read a file.

CR will move the "current printing" to the beginning of the line, without erasing or otherwise changing the text on the line.

--
Mats

[Salem]

> char *buff[2049];
Are you even getting any warnings when you use this?

There is a world of difference between this and char buff[2049]

> strGet(buf, " ", 3, buff);
From your description of the function, you're using buf as an output parameter, yet there is no evidence that you've allocated any space.

I would suggest you review all your usage of char arrays and pointers to make sure that you're always pointing at some allocated space. Simply declaring a char* variable because that's the type the function expects isn't good enough.

And also make sure it compiles without any warnings, because to be honest, it looks like sloppy coding to me.

[cyreon]

Oh sorry salem. The char *buff[2049] was a typo on my part, it should have been char buff[2049].

As well char *buf is an input to the function that code is contained within, not an output. In the case of strGet() buf is being passed in as the raw data coming in on a network connection, strGet will then take the other parameters (2nd one is the separator between items in the string, 3rd indicates the nth item for it to grab out of the raw data, and the 4th is the buffer in which to store the information that is being asked for). Thus, buff is being used, in this case, to store the information I need.

Hope that clarifies things.