printf problem

This is a discussion on printf problem within the C Programming forums, part of the General Programming Boards category; Now I'm not sure if anyone else has ever run in to a problem such as this, however, I would ...

  1. #1
    uh oh
    Join Date
    Jan 2005
    Location
    Ontario, CA
    Posts
    66

    printf problem

    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...

    Code:
    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:
    Code:
    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.

  2. #2
    Registered User
    Join Date
    Oct 2001
    Posts
    2,934
    How is buff declared?

  3. #3
    Devil™
    Join Date
    Oct 2007
    Location
    IIT-Kharagpur, India
    Posts
    104
    Quote Originally Posted by cyreon View Post
    Code:
        strGet(buf, " ", 4, btmp);
        strRem(btmp, ":", 1);
    what are these?

    Code:
    buff, buf;
    good way to save time from typing long variable names.. but make sure that you wont revisit your code again
    C's Motto: who cares what it means? I just compile it!!

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Looks to me like "Btmp" has a newline on the end.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #5
    uh oh
    Join Date
    Jan 2005
    Location
    Ontario, CA
    Posts
    66
    For swoopy and gibsosmat:

    the variables are declared as follows:
    Code:
    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:
    Code:
    // 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.

  6. #6
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Try printing the strings involved as hex-numberes, eg:
    Code:
    #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:
    Code:
    string myVar:
    +++
    48 69 21 0a
    ***
    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #7
    uh oh
    Join Date
    Jan 2005
    Location
    Ontario, CA
    Posts
    66
    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).

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  9. #9
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,755
    > 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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  10. #10
    uh oh
    Join Date
    Jan 2005
    Location
    Ontario, CA
    Posts
    66
    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.
    Last edited by cyreon; 11-08-2007 at 09:22 AM. Reason: Better clarification.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Problems reading entered race times C
    By loopymoo26 in forum C Programming
    Replies: 12
    Last Post: 05-23-2009, 08:38 AM
  2. Help with a C Programing Quiz project
    By dilemma in forum C Programming
    Replies: 12
    Last Post: 05-15-2009, 04:35 PM
  3. A question related to strcmp
    By meili100 in forum C++ Programming
    Replies: 6
    Last Post: 07-07-2007, 03:51 PM
  4. error in program????
    By SpEkTrE in forum C Programming
    Replies: 5
    Last Post: 11-24-2003, 06:16 PM
  5. Drawing tables in C
    By stanoman in forum C Programming
    Replies: 5
    Last Post: 10-09-2003, 11:14 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21