The build log of a program might contain nul characters. Currently if it does, there is no way to retrieve the log as Program::get_build_log() only returns Err(-9999) ( CSTRING_UTF8_CONVERSION_ERROR) when it encounters a nul.
A potential fix could be something along the lines of the following code, which strips away all nul characters.
diff --git a/src/program.rs b/src/program.rs
index 7cd8541..3b8271c 100644
--- a/src/program.rs
+++ b/src/program.rs
@@ -304,7 +304,14 @@ impl Program {
pub fn get_build_log(&self, device: cl_device_id) -> Result<CString, cl_int> {
get_program_build_info(self.program, device, ProgramBuildInfo::CL_PROGRAM_BUILD_LOG)?
.to_str()
- .map_err(|_| error_codes::CSTRING_UTF8_CONVERSION_ERROR)
+ .or_else(|nul_error| {
+ Ok(CString::new(
+ std::str::from_utf8(&nul_error.into_vec())
+ .unwrap()
+ .replace('\0', ""),
+ )
+ .unwrap())
+ })
}
pub fn get_build_binary_type(&self, device: cl_device_id) -> Result<cl_uint, cl_int> {When reading the spec it also seems that usually strings don't contain any nul characters within the string (and if they could (like CL_PROGRAM_SOURCE they are stripped away. So it won't make sense to change the general approach of returning Cstrings.
The build log of a program might contain
nulcharacters. Currently if it does, there is no way to retrieve the log asProgram::get_build_log()only returnsErr(-9999)(CSTRING_UTF8_CONVERSION_ERROR) when it encounters anul.A potential fix could be something along the lines of the following code, which strips away all
nulcharacters.When reading the spec it also seems that usually strings don't contain any
nulcharacters within the string (and if they could (like CL_PROGRAM_SOURCE they are stripped away. So it won't make sense to change the general approach of returningCstrings.