Bugs item #2233581, was opened at 2008-11-07 10:53 Message generated for change (Comment added) made by sjoerd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2233581&group_id=56967
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: SQL/Core Group: MonetDB5 "stable" Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Neumann (tneumann) Assigned to: Niels Nes (nielsnes) Summary: MonetDB does not like '\0' in its input Initial Comment: Both the mclient client and the monetdb server do not seem to like '\0' (i.e., the ASCII character 0) as part of their input. The following command causes the client the exit when run with mclient -l sql create table strings(id int not null primary key, value varchar(16400) not null); copy 3 records into "strings" from stdin using delimiters '\t'; 1 "some string" 2 "\0" 3 "some other string" (Note that the "\0" must contain the character 0, not the escape sequence!) In the context of a larger input statement the server crashed, too. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2008-11-08 17:22 Message: I interpreted the code in Mapi.mx incorrectly (the strncpy that I mentioned is actually not relevant), but your "fix" is not a fix at all since you still use strncpy. That function stops at the first NUL byte, and since your "fix" still uses strncpy, the copy still stops there. However, this is totally irrelevant to the problem, since it is not the copied string which is sent to the server, it is the original string, or rather buffer. And that is sent using a count so the NUL byte and anything that follows that is also sent to the server. If you read the comment (that you also changed in the process), you see that the copy is used for error messages only. So there is actually not a problem in mclient. This last remark is, however, only true if mclient reads from a file which was passed on the command line as command line argument. In that case (and if you use \< in an interactive mclient), the function doFile is used which uses fread to read from the file, and fread works fine with NUL bytes. In the interactive case however, the function doFileByLine is used which uses either the readline library or fgets, both of which do not handle embedded NUL bytes. So in that case the NUL byte will never be sent to the server. ---------------------------------------------------------------------- Comment By: Martin Kersten (mlkersten) Date: 2008-11-08 09:36 Message: The limitation on the buffer size in mapi_query_part has been dropped. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2008-11-07 11:12 Message: I have already found two places that can't cope with embedded NULs. In mapi_query_part(Mapi.mx) there is a strncpy to copy the query to a buffer. This stops at the NUL. In this case we even have the length of the query (i.e. also the bit beyond the NUL), but that part is blissfully ignored. In TABLETload_bulk(tablet.mx) there is a search for the line terminator to see whether more data needs to be loaded. This is done using strstr which stops at the NUL byte. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2233581&group_id=56967 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Monetdb-bugs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
