Using 16-bit format specifier for 32-bit integer: can it cause random faliures?

I have the following (in a 16-bit environment)

char * myFunc(char *lbuf, int_32 MyLong)
{
  char buffer[30];
  char MyName[20];

...
  sprintf(buffer, "%6.6s%05d", MyName, MyLong)
}
|The above statement appears to me to be wrong, as MyLong is a long and I'm using a 16-bit format spec to output it.

My question is: can such a  bug cause random failures in this functiion? By that, I mean that when the calling function tried to output MyFunc's returnvalue to a text file, it would write nothing to the file.
This behavior was RANDOM: for example, I'd run the program once, it would work. Then I would REMOVE a line of code from the calling function THAT WASN'T EVEN EXECUTED IN THAT RUN OF THE PROGRM, and it would fail.

Please advise.
Thanks,
Steve
LVL 4
Stephen KairysTechnical Writer - ConsultantAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
Infinity08Connect With a Mentor Commented:
>> as MyLong is a long and I'm using a 16-bit format spec to output it.

Use %ld instead of %d, and it should work fine ...
0
 
Infinity08Commented:
You didn't show the code that returns the string ... If it looks like this :

        char * myFunc(char *lbuf, int_32 MyLong)
        {
          char buffer[30];
          char MyName[20];
       
          /* ... */
       
          sprintf(buffer, "%6.6s%05d", MyName, MyLong);
          return buffer;                                                                 /* <--- this is wrong !!! */
        }

then you'll have to fix that - you're returning a pointer to a local buffer (that is no longer valid when the function has ended).
If it's different, can you show the code ?
0
 
Infinity08Commented:
>> My question is: can such a  bug cause random failures in this functiion? By that, I mean that when the calling function tried to output MyFunc's returnvalue to a text file, it would write nothing to the file.

It shouldn't, no. It might show the wrong data, but it should show something.
0
The IT Degree for Career Advancement

Earn your B.S. in Network Operations and Security and become a network and IT security expert. This WGU degree program curriculum was designed with tech-savvy, self-motivated students in mind – allowing you to use your technical expertise, to address real-world business problems.

 
Stephen KairysTechnical Writer - ConsultantAuthor Commented:
Infinity08,
Thankfully, I do not return a pointer to a local variable. Rather, I have something like this:


        char * myFunc(char *lbuf, int_32 MyLong)
        {
          char buffer[30];
          char MyName[20];
       
          /* ... */
       
          sprintf(buffer, "%6.6s%05d", MyName, MyLong);
          ....
          return lbuf;  // which is populated further up and is a function parameter.
        }

And then in the calling routine:

 fprintf(out_fp, "BARCODE=\"%s\"\n", myFunc(some_buffer, some_long));

Thanks
0
 
Infinity08Commented:
>>           return lbuf;  // which is populated further up and is a function parameter.

And I assume it's got enough room for what you put in it ...
0
 
Stephen KairysTechnical Writer - ConsultantAuthor Commented:
>> >>           return lbuf;  // which is populated further up and is a function parameter.

>> And I assume it's got enough room for what you put in it ...

Yep, it is. Thanks.
0
 
Infinity08Connect With a Mentor Commented:
>> This behavior was RANDOM: for example, I'd run the program once, it would work. Then I would REMOVE a line of code from the calling function THAT WASN'T EVEN EXECUTED IN THAT RUN OF THE PROGRM, and it would fail.

I haven't mentioned this, but this behavior can occur with unmatched printf format specifiers. Basically, the printf function expects certain data on the stack, and if you put different data on the stack, it will interpret that data as if it were the data that it expected.
0
 
Stephen KairysTechnical Writer - ConsultantAuthor Commented:
Hi again.
Turns out, while there was a wrong format spec in the instance I alluded to above, the bug in my priogram was an old-fashioned memory overrwrite of a buffer (in a statement right before the call to the function to which I alluded).  Fixing the memory issue fixed the bug.

But, I still changed the format spec to what it should be in the instance I referred to (actually 2 of them).

Thanks for your help.
-Steve
0
 
Stephen KairysTechnical Writer - ConsultantAuthor Commented:
THANKS AGAIN for your help!!
0
 
Infinity08Commented:
>> the bug in my priogram was an old-fashioned memory overrwrite of a buffer

Yep ... That would do it :) I wasn't too far off lol :

>> And I assume it's got enough room for what you put in it ...

just another buffer ...
0
 
Stephen KairysTechnical Writer - ConsultantAuthor Commented:
Yeah. The buffer was declared with length of 2, because the original programmer expected the data coming into it to never be more than 1 char in length. Problem was in one case, it would be 6 chars. in length.

And it was right in front of me too....lesson learned for next time. Check ANY buffers in the neighborhood of the "problem". :)
0
 
Infinity08Commented:
heh :)
0
All Courses

From novice to tech pro — start learning today.