odbc: check SQLColAttribute return codes in the field info functions - #23601
odbc: check SQLColAttribute return codes in the field info functions#23601iliaal wants to merge 1 commit into
Conversation
odbc_column_lengths() and odbc_field_type() ignored the SQLColAttribute return code and returned their output buffer regardless, so a driver that fails the call left odbc_field_len(), odbc_field_scale() and odbc_field_type() reporting uninitialized stack. Check the code, warn with the driver's own diagnostic, and return 0 or false instead. Closes phpGH-23601
50c63c5 to
045dd07
Compare
NattyNarwhal
left a comment
There was a problem hiding this comment.
I think this makes sense. I think in master we should consider making odbc_sql_error a sprintf-type thing so we can do something like "SQLAttribute column #%d",, so we can get rid of odbc_colattribute_failed. There's a few places where SQLError is called too, so more cleanup there...
|
Agreed for master, but as its own PR rather than folded into the up-merge. Routing these through The SQLError cleanup isn't mechanical either. The one in odbc_cursor() reads SQLSTATE S1015 and synthesizes a cursor name from it, so it's control flow rather than reporting. |
|
Yeah, it should be a separate PR. I'll take a look at your new one |
odbc_column_lengths()andodbc_field_type()ignored theSQLColAttributereturn code and returned their output buffer regardless, so a driver that fails the call leftodbc_field_len(),odbc_field_scale()andodbc_field_type()reporting uninitialized stack. They now check the code and warn with the driver's ownSQLGetDiagRecdiagnostic.odbc_bindcols()gets the one-line zero-init ofnamefor the same reason; it has no way to report an error, since it runs during result setup and returns void. No test: reaching the branch needs a driver that failsSQLColAttributeon a valid column index, and there is no existing php-src harness for injecting that.