String in hands of dumb****s
-
So, yesterday I received a bug " Explain SQL sometimes (!) does not work on Oracle." Twist, test, try, WTF of course. The mistery: Format of a string class (almost any). So here's how (with comments, bells, and COM follies):
String strDest; // target for a some kind of "-u<user> -p<password>..." or so called packed args
String strUser; // emptystrDest.Format(_T("-u%s"), strUser);
Unfortunately, Format call replaces "%s" with "(null)" when a null argument is passed as string. So the poor receiver attempted to decode the "-u(null)" into an user name, and he gets "(null)". Then the string horror (of course yet again not validated and unpacked without any defense) was passed to yet another string statement, so it ended up in "ALTER SESSION SET CURRENT_SCHEMA = (null)" Obviously a valid string, but probably the customer does not have an user called "(null)". I hope.
Nuclear launch detected
//
-
So, yesterday I received a bug " Explain SQL sometimes (!) does not work on Oracle." Twist, test, try, WTF of course. The mistery: Format of a string class (almost any). So here's how (with comments, bells, and COM follies):
String strDest; // target for a some kind of "-u<user> -p<password>..." or so called packed args
String strUser; // emptystrDest.Format(_T("-u%s"), strUser);
Unfortunately, Format call replaces "%s" with "(null)" when a null argument is passed as string. So the poor receiver attempted to decode the "-u(null)" into an user name, and he gets "(null)". Then the string horror (of course yet again not validated and unpacked without any defense) was passed to yet another string statement, so it ended up in "ALTER SESSION SET CURRENT_SCHEMA = (null)" Obviously a valid string, but probably the customer does not have an user called "(null)". I hope.
Nuclear launch detected
//
That's why I like to verify all input before passing it on. A couple "if" constructs looking for NULLs and such isn't a bad thing to throw in from time to time. if (strUser !="") { strDest.Format(_T("-u%s"), strUser); } else { // Add code to complain here } Checking for "stupid user tricks" is half the battle of coding! I tend to be very paranoid about anything "editable" by users, and check the bejezzus out of it before passing it along.
-
That's why I like to verify all input before passing it on. A couple "if" constructs looking for NULLs and such isn't a bad thing to throw in from time to time. if (strUser !="") { strDest.Format(_T("-u%s"), strUser); } else { // Add code to complain here } Checking for "stupid user tricks" is half the battle of coding! I tend to be very paranoid about anything "editable" by users, and check the bejezzus out of it before passing it along.
-
So, yesterday I received a bug " Explain SQL sometimes (!) does not work on Oracle." Twist, test, try, WTF of course. The mistery: Format of a string class (almost any). So here's how (with comments, bells, and COM follies):
String strDest; // target for a some kind of "-u<user> -p<password>..." or so called packed args
String strUser; // emptystrDest.Format(_T("-u%s"), strUser);
Unfortunately, Format call replaces "%s" with "(null)" when a null argument is passed as string. So the poor receiver attempted to decode the "-u(null)" into an user name, and he gets "(null)". Then the string horror (of course yet again not validated and unpacked without any defense) was passed to yet another string statement, so it ended up in "ALTER SESSION SET CURRENT_SCHEMA = (null)" Obviously a valid string, but probably the customer does not have an user called "(null)". I hope.
Nuclear launch detected
//
-
That's why I like to verify all input before passing it on. A couple "if" constructs looking for NULLs and such isn't a bad thing to throw in from time to time. if (strUser !="") { strDest.Format(_T("-u%s"), strUser); } else { // Add code to complain here } Checking for "stupid user tricks" is half the battle of coding! I tend to be very paranoid about anything "editable" by users, and check the bejezzus out of it before passing it along.
Your check would still not catch the NULL value. A much better way to validate all strings would be: if (String.IsNullOrEmpty(strUser)){ throw new ArgumentNullException(strUser); } else { strDest.Format(... } Hope this helps. .leON.
-
Your check would still not catch the NULL value. A much better way to validate all strings would be: if (String.IsNullOrEmpty(strUser)){ throw new ArgumentNullException(strUser); } else { strDest.Format(... } Hope this helps. .leON.
Yep - it's a better check, assuming one is working in C# or with .NET. Personally, I tend to do most of my development in C or C++ without ever touching any .NET stuff, and tend to fall into that pattern instead. It's the nature of my apps being low-level stuff for the most part that drives this, plus I like working with pointers!
-
So, yesterday I received a bug " Explain SQL sometimes (!) does not work on Oracle." Twist, test, try, WTF of course. The mistery: Format of a string class (almost any). So here's how (with comments, bells, and COM follies):
String strDest; // target for a some kind of "-u<user> -p<password>..." or so called packed args
String strUser; // emptystrDest.Format(_T("-u%s"), strUser);
Unfortunately, Format call replaces "%s" with "(null)" when a null argument is passed as string. So the poor receiver attempted to decode the "-u(null)" into an user name, and he gets "(null)". Then the string horror (of course yet again not validated and unpacked without any defense) was passed to yet another string statement, so it ended up in "ALTER SESSION SET CURRENT_SCHEMA = (null)" Obviously a valid string, but probably the customer does not have an user called "(null)". I hope.
Nuclear launch detected
//