• C

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?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
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 Lifecycle Approach to Managing Security Policy

Managing application connectivity and security policies can be achieved more effectively when following a framework that automates repeatable processes and ensures that the right activities are performed in the right order.

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
Infinity08Commented:
>> 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
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
C

From novice to tech pro — start learning today.