----- Original Message ----- > On 12/17/2014 11:29 AM, Niels de Vos wrote: > > On Wed, Dec 17, 2014 at 10:24:46AM +0100, Xavier Hernandez wrote: > >> I think the root cause of this particular problem is a pattern like this: > >> > >> GF_ASSERT(type <= x); > >> > >> array[type] = y > >> > >> I think there are several places where this pattern is used. GF_ASSERT() > >> is > >> there to detect bugs, however it does not stop the execution, it simply > >> logs > >> the problem. So if there's really a bug and 'type' > x, we will do an > >> incorrect access into the array. Additionally, if 'type' is obtained from > >> a > >> tainted pointer, coverity considers this a potential security issue. > >> > >> This is also applicable to NULL pointer checks and some others. This issue is because we are reading contents of a file into a fixed sized buffer. Coverity considers external sources like I/O as taint by default. My original question was if there are ways by which we can programmatically let Coverity know that the data is _not_ tainted. This could be a Coverity primitive, like explained here https://communities.coverity.com/thread/2303, or refactoring our code. AFAICS, this pattern is not the same as boundary checks. (NB. buffer in question is fixed length array and fgets (I/O) was performed with sizeof (buffer) as the limit.) _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel