netdev - Re: [PATCH 1/3 net-next RFC] selftest: add abstractions for net selftests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5163FC37.4090202@redhat.com>
Date:	Tue, 09 Apr 2013 13:32:07 +0200
From:	Daniel Borkmann <dborkman@...hat.com>
To:	Alexandru Copot <alex.mihai.c@...il.com>
CC:	netdev@...r.kernel.org, davem@...emloft.net, willemb@...gle.com,
	edumazet@...gle.com, Daniel Baluta <dbaluta@...acom.com>
Subject: Re: [PATCH 1/3 net-next RFC] selftest: add abstractions for net selftests

On 04/09/2013 01:24 PM, Alexandru Copot wrote:
> On Tue, Apr 9, 2013 at 2:13 PM, Daniel Borkmann <dborkman@...hat.com> wrote:

>>> +#define CHECK(cond,fmt,...)                            \
>>> +       do {                                            \
>>> +               if (!(cond)) {                          \
>>> +                       fprintf(stderr, "(%s, %d): " fmt,       \
>>> +                                       __FILE__, __LINE__,
>>> ##__VA_ARGS__); \
>>> +                       perror("");                     \
>>> +                       return 1;                       \
>>> +               }                                       \
>>> +       } while (0)
>>
>>
>> Isn't it a bit error-prone if in the middle of somewhere this check fails
>> and the function suddenly returns 1?
>>
>> What if this is called from a function that was declared as void or to
>> return a pointer to a struct etc.?
>
> Well, I tought of using this only in your high-level testcase methods
> (test->run()).
> It is also easier to see what is actually being tested.
>
> For anything else the user is free to use any other functions or
> return conventions
> as the test requires.

Hm, then, still not convinced about the CHECK macro. In worst case this at
least needs a comment, so that people will not misuse that, but with your
two statements above, it seems likely that people could also start using it
in "any other functions or return conventions as the test requires". ;-)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html