On Thursday, August 02, 2012 09:42:06 PM Thiago Marcos P. Santos wrote: > On Thu, Aug 2, 2012 at 9:04 PM, Paul Moore <[email protected]> wrote: > > On Thursday, August 02, 2012 06:36:49 PM [email protected] wrote: > > > > > > It is always nice to provide this alternative version of variadic > > > functions since there is no portable way of wrapping them. > > > > Hmm, this would have been nice last week when I asked for any API changes. > > It doesn't mean we can't add it, just that the bar is a little bit higher > > now. > > > > I understand the basic why, but can you provide a concrete example of an > > application which needs this functionality? > > > > I'm also not sure about the new function names, I would like to keep the > > API "namespaced" with the "seccomp_" prefix ... maybe tack a "_va" on the > > end instead? > > > > I have a class called SeccompFilters. I want to keep the seccomp context > private and at the same time I want to let people add rules by using the > addRule() method. For that I would need something like the code bellow. > > void SeccompFilters::addRule(uint32_t action, int syscall, unsigned int... > { > va_list args; > va_start(args, arg_cnt); > > > int rc = seccomp_rule_add_va(m_context, action, syscall, arg_cnt, args); > // error handling, failure is fatal > > > va_end(args); > } > > I'm tempted to handle every error when adding filters as fatal. People > willing to do the same, no matter if it is C or C++, can use the _va > functions to create a wrapper. C99 supports variadic macro, which might help > C developers, but doesn't solve my case because it could only be used inside > the class. > > #define seccomp_rule_add_or_crash(context, action, syscall, arg_cnt, ...) \ > ASSERT(seccomp_rule_add(context, action, syscall, arg_cnt, > ##__VA_ARGS__) >= 0);
First off, *please* no more HTML mail. I dislike having to remove the markup and reformat your email in my reply. It also has a tendency to make me cranky, and I'm less likely to apply patches when I'm cranky. Anyway, back to the substance of your email ... Thanks for the example. In this particular case I think I would rather see us implement a structure which could be used to specify the arg/op/value combinations and pass a pointer to an array in the new rule_add APIs. The existing va_list based approach was designed to make it easier for developers by reducing the amount of work they had to do beyond just the function call, and while I think it succeeds for the most part, there are a lot of drawbacks around types and just safety in general. A structure based API removes many of these problems, and in your example shouldn't add too much burden to the developer. Thoughts? > If you are curious about for what purpose this code has being worked on: > https://bugs.webkit.org/show_bug.cgi?id=89875 Cool, thanks for this. Are you targeting any specific browser, or just WebKit in general right now? > And I'm totally fine on changing the name. My original inspiration was the > [v]printf() family, but I guess it works for libc because they don't care > about namespace. Yeah, your logic does make sense, I just think there is value in keeping the API prefaced with a "seccomp_" to both help in identifying the library functions in other code and to ensure we don't collide with anything else. -- paul moore security and virtualization @ redhat ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libseccomp-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss
