dpiDataBuffer__toOracleNumberFromText overruns 1 byte for a negative number whose number of digits is 39.

[kubo]

When a negative number whose number of digits is 39 such as -123456789012345678901234567890123456789 is converted to an Oracle number, dpiDataBuffer__toOracleNumberFromText() overruns 1 byte.

How to check it.

1. Change here as follows.

      if (appendSentinel) {
           *target = 102;
           fprintf(stderr, "offset = %d\n", target - (uint8_t*)oracleValue);
       }

2. Download this file and run it.
   Edited: The posted file doesn't provide the issue. Change a number in the file as my next post to reproduce it.

The program prints offset = 22. So the sentinel 102 was written at 23th byte. However the size of Oracle number is 22.

[anthony-tuininga]

I just tried doing this and I don't get those results. @cjbj, did you get @kubo's results? The code that sets "appendSentinel" sets it to the value 0 for me using the provided code. This is on Linux. Perhaps you are using a different platform?

[anthony-tuininga]

And I just tried on macOS as well and don't see these results there either.

[kubo]

Thanks for trying it not only on Linux, but also on macOS.
I'm using Linux (Ubuntu 16.04, gcc 5.4.0).

Sorry, I moved the fprintf() into if (appendSentinel) { ... } just before submitting the issue.
I might forget to recompile it at that time. However buffer overrun exists for other numbers.
I noticed it when I translated the text-to-OracleNumber conversion code to rust.

Could you change the sample code as follows?
from:

    const char *num_str = "-123456789012345678901234567890123456789";

to:

    const char *num_str = "-12345678901234567890123456789012345678.9";

The modified code prints:

offset = 22
ERROR at line 60
  dpiStmt_execute(stmt, 0, &numQueryColumns)
  ORA-01458: invalid length inside variable character string

The ERROR at line 60 seems to be caused by the buffer overrun.

[cjbj]

No issues with 11.2 or 12.2 client to an 18c DB on Linux. The appendSentinel check wasn't triggered.

[cjbj]

The data "-12345678901234567890123456789012345678.9" does produce output "offset = 22" on Linux x64 with 11.2 & 12.2 clients.

[anthony-tuininga]

@kubo, thanks for the clarification. As you can see from the commit I just made, there was code following the check on the number of digits that increased the number of digits, which resulted in the buffer overrun you noted. I have now corrected this. Thanks for pointing this out!