Dear Friends!:
I've been compiling this code:
https://github.com/bsalunke/SysCallInterceptModule
and when executing make or ./compile.sh, it's report this error:
/MyPath/SysCallInterceptModule-master/Module/SysCallInterceptModule.c:244:12: error: initialization of ‘ssize_t (*)(struct file *, char *, size_t,
loff_t *)’ {aka ‘long int (*)(struct file *, char *, long unsigned int,
long long int *)’} from incompatible pointer type ‘int (*)(struct file *, char *, size_t, loff_t)’ {aka ‘int (*)(struct file *, char *, long unsigned int, long long int)’} [-Werror=incompatible-pointer-types]
The error stops being reported if I replace line 244 with:
.read = (ssize_t (*)(struct file *, char *, size_t, loff_t *)) &device_read,
But was that really necessary? I went through all the source code and
couldn't find any other struct file_operations with a read function defined this way:
int (*)(struct file *, char *, long unsigned int, long long int)’}
The error also didn't disappear if I declared the read function on line 147
as:
static ssize_t device_read(struct file* filep, char* buffer, size_t len, loff_t offset){
I appreciate any explanation on why this occurs and / or any different solutions to avoid the error. Personally, it doesn't seem very logical to
me.
<div dir="ltr"><div>Dear Friends!:<br><br>I've been compiling this code: <a href="
https://github.com/bsalunke/SysCallInterceptModule" target="_blank">
https://github.com/bsalunke/SysCallInterceptModule</a><br>and when executing make or ./compile.sh,
it's report this error:</div><div><br></div><div>/MyPath/SysCallInterceptModule-master/Module/SysCallInterceptModule.c:244:12: error: initialization of ‘ssize_t (*)(struct file *, char *, size_t, loff_t *)’ {aka ‘long int (*)(struct file *,
char *, long unsigned int, long long int *)’} from incompatible pointer type ‘int (*)(struct file *, char *, size_t, loff_t)’ {aka ‘int (*)(struct file *, char *, long unsigned int, long long int)’} [-Werror=incompatible-pointer-types]</
<div><br></div><div><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span>The error stops being reported if I replace line 244 with:</span></span></span></div><div><span class="gmail-VIiyi" lang="en"><span class="gmail-
JLqJ4b gmail-ChMk0b"><span><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span> .read = (ssize_t (*)(struct file *, char *, size_t, loff_t *)) &device_read,</span></span></span></span></span></span></div><div><span
class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span><br></span></span></span></span></span></span></div><div><span class="gmail-VIiyi" lang="en"><
span class="gmail-JLqJ4b gmail-ChMk0b"><span><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span>But was that really necessary? <span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span>I went
through all the source code and couldn't find any other struct file_operations with a read function defined this way:</span></span></span> </span></span></span></span></span></span></div><div><span class="gmail-VIiyi" lang="en"><span class="gmail-
JLqJ4b gmail-ChMk0b"><span><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span><br></span></span></span></span></span></span></div><div><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span><span
class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span>int (*)(struct file *, char *, long unsigned int, long long int)’}</span></span></span></span></span></span></div><div><span class="gmail-VIiyi" lang="en"><span class="gmail-
JLqJ4b gmail-ChMk0b"><span><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span><br></span></span></span></span></span></span></div><div><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span><span
class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span>The error also didn't disappear if I declared the read function on line 147 as:</span></span>
</span> </span></span></span></span></span></span></div><div><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span><br></span></span></span></
span></span></span></div><div><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span>static ssize_t device_read(struct file* filep, char*
buffer, size_t len, loff_t offset){</span></span></span></span></span></span></div><div><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span><
</span></span></span></span></span></span></div><div><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span>I appreciate any explanation on
why this occurs and / or any different solutions to avoid the error. Personally, it doesn't seem very logical to me.</span></span></span></span></span></span></div><div><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span>
<span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span><br></span></span></span></span></span></span></div><div><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span><span class="gmail-VIiyi" lang="
en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span><br></span></span></span></span></span></span></div><div><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b
gmail-ChMk0b"><span><br></span></span></span> </span></span></span></div></div>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)