Fix time(0) buffer overwrite

[bmharper]

The change in types.go fixes a buffer overrun when encoding to a time(0) field.

However, this change still doesn't fix the fact that any time field except for time(7) causes a BCP protocol failure.

In the test that I have added, I create a time(0) field, and this causes the test to fail. Note that it is not just time(0) that fails. All precision values from 0..6 cause the test to fail.

I have read the protocol documentation in https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-tds/ce3183a6-9d89-47e8-a02f-de5a1a1303de and cross-referenced it with the calcTimeSize and encodeTimeInt functions, and the Go code looks correct. I have also tried hardcoding a returned buffer of all sizes from 1 to 5 bytes, but they all yield the same BCP error.

In summary, even if nobody can figure out how to make time(0..6) fields work, I think it's still a good idea to merge my change to types.go, to fix the buffer overrun.

[shueybubbles]

thx for the contribution!

Have you tried using bcp.exe to create a format file for a table having this column to see what ODBC does with it in native mode?

The TDS doc doesn't even list 0 as an option for scale.

[shueybubbles]

func encodeTimeInt(seconds, ns, scale int, buf []byte) {

Blind writing to a buffer of unknown size violates every standard of coding I've ever been held to.
Shouldn't we harden this function to check len(buf) and only write that number up to the limit of 5?

---

Refers to: types.go:901 in 01f253b. [](commit_id = 01f253b, deletion_comment = False)

[shueybubbles]

// buffer should be at least calcTimeSize long

if the function isn't made safer by checking len(byte), at minimum change this comment to say "5 long" and it could panic if len(buf) is not at least 5. Better to panic with a good message than to have the buffer overrun isn't it?

---

Refers to: types.go:900 in 01f253b. [](commit_id = 01f253b, deletion_comment = False)

[bmharper]

My experience with SQL Server is very limited, so I don't quite understand what you mean by "Have you tried using bcp.exe to create a format file for a table having this column to see what ODBC does with it in native mode?"

But as for your comments on the buffer size, I agree 100%. That was my first instinct, and I think that a panic is probably the right move.

[shueybubbles]

bcp is the standard bulk copy command line tool, it's available with SQL Server on Windows and as a Linux tools package.

See https://learn.microsoft.com/sql/relational-databases/import-export/create-a-format-file-sql-server?view=sql-server-ver15#a-create-a-non-xml-format-file-for-native-data

---

In reply to: 1311775759

[bmharper]

My thought on how to proceed from here was to run wireshark to look at the bytes sent over the wire from bcp to an SQL Server instance, to figure out what it does. Is there an easier way to achieve that with bcp, without involving wireshark?

[bmharper]

bcp is the standard bulk copy command line tool, it's available with SQL Server on Windows and as a Linux tools package.

See https://learn.microsoft.com/sql/relational-databases/import-export/create-a-format-file-sql-server?view=sql-server-ver15#a-create-a-non-xml-format-file-for-native-data

In reply to: 1311775759

OK thanks.. I'll try that command first, and see if that gives me any clues.

[shueybubbles]

you could bcp out the data from the table to a native format data file. Those bytes will match the wire format afaik