sizeof (struct tYpO *) : it is just a typo or rather a bug ?

sizeof (struct tYpO *) : it is just a typo or rather a bug ?

[Toralf Förster]

Inspired by this "typo" fix 
http://article.gmane.org/gmane.linux.kernel/1754640
I grep'ed the current git tree of linus for similar issues.

For these 4 places I'm wondering where the appropriate struct definition is located :

arch/ia64/sn/kernel/io_acpi_init.c:         sizeof(struct pci_devdev_info *)) {
tools/perf/builtin-sched.c:     sched->tasks = realloc(sched->tasks, sched->nr_tasks * sizeof(struct task_task *));
fs/ceph/xattr.c:                xattrs = kcalloc(numattr, sizeof(struct ceph_xattr *),
fs/ceph/xattr.c:                memset(xattrs, 0, numattr*sizeof(struct ceph_xattr *));

Nevertheless I was told, that gcc doesn't complain about such things due to eventually evaluating it to "sizeof(null)". I'm however curious if at least a warning should be emitted in such a case, or?

-- 
Toralf

Re: sizeof (struct tYpO *) : it is just a typo or rather a bug ?

[Ilya Dryomov]

On Thu, Jul 24, 2014 at 10:20 PM, Toralf Förster <toralf.foerster@gmx.de> wrote:
> Inspired by this "typo" fix
> http://article.gmane.org/gmane.linux.kernel/1754640
> I grep'ed the current git tree of linus for similar issues.
>
> For these 4 places I'm wondering where the appropriate struct definition is located :
>
> arch/ia64/sn/kernel/io_acpi_init.c:         sizeof(struct pci_devdev_info *)) {
> tools/perf/builtin-sched.c:     sched->tasks = realloc(sched->tasks, sched->nr_tasks * sizeof(struct task_task *));
> fs/ceph/xattr.c:                xattrs = kcalloc(numattr, sizeof(struct ceph_xattr *),
> fs/ceph/xattr.c:                memset(xattrs, 0, numattr*sizeof(struct ceph_xattr *));

Heh, the ceph one is a five year old typo..  Looks like it should be
struct ceph_inode_xattr, I'll fix it up.  I'm curious though, how did
you grep for these?

Thanks,

                Ilya

Re: sizeof (struct tYpO *) : it is just a typo or rather a bug ?

[Toralf Förster]

On 07/24/2014 08:33 PM, Ilya Dryomov wrote:
> On Thu, Jul 24, 2014 at 10:20 PM, Toralf Förster <toralf.foerster@gmx.de> wrote:
>> Inspired by this "typo" fix
>> http://article.gmane.org/gmane.linux.kernel/1754640
>> I grep'ed the current git tree of linus for similar issues.
>>
>> For these 4 places I'm wondering where the appropriate struct definition is located :
>>
>> arch/ia64/sn/kernel/io_acpi_init.c:         sizeof(struct pci_devdev_info *)) {
>> tools/perf/builtin-sched.c:     sched->tasks = realloc(sched->tasks, sched->nr_tasks * sizeof(struct task_task *));
>> fs/ceph/xattr.c:                xattrs = kcalloc(numattr, sizeof(struct ceph_xattr *),
>> fs/ceph/xattr.c:                memset(xattrs, 0, numattr*sizeof(struct ceph_xattr *));
> 
> Heh, the ceph one is a five year old typo..  Looks like it should be
> struct ceph_inode_xattr, I'll fix it up.  I'm curious though, how did
> you grep for these?
> 
> Thanks,
> 
>                 Ilya
> 

1:
	grep -Hr "sizeof[ *(]struct .* \*.)"  | cut -f2- -d':' | tee ~/tmp/out

2:
	cat ~/tmp/out | perl -wane 'chomp(); my ($left, $right) = split (/sizeof\(/); print $right, "\n";' | cut -f2 -d' ' | sort -u | cut -f1 -d')' | grep -v '^+' | while read i; do echo $i; git grep -q "struct $i {" || echo error; echo; done

3:
	ignore false positives

-- 
Toralf

Re: sizeof (struct tYpO *) : it is just a typo or rather a bug ?

[Henrique de Moraes Holschuh]

On Thu, 24 Jul 2014, Toralf Förster wrote:
> Inspired by this "typo" fix 
> http://article.gmane.org/gmane.linux.kernel/1754640
> I grep'ed the current git tree of linus for similar issues.

I wonder if we couldn't use Coccinelle to do that?  I would say it would be
not as cool as deep grep magick, but Coccinelle is cool by definition and
therefore immune from any such comparisons :-)

> Nevertheless I was told, that gcc doesn't complain about such things due
> to eventually evaluating it to "sizeof(null)". I'm however curious if at
> least a warning should be emitted in such a case, or?

Well, it cannot become a real bug because the moment the code changes to
actually access/derreference such a typo, it will cause the compiler to
abort with an error.  If gcc will have to waste a measurable amount of time
to issue such a warning, it is not worth it.

OTOH, such typos could confuse someone reading the code into thinking
they're dealing with a different structure or something, and it _is_
incorrect code no matter how harmless, so it makes sense to fix all such
typos eventually.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh