Re: [ SEPOL ] Move more things to newer debug system

[Joshua Brindle <jbrindle@tresys.com>]

Stephen Smalley wrote:

>On Wed, 2005-09-14 at 09:21 -0400, Joshua Brindle wrote:
>  
>
>>Fair enough, for things like assertion and hierarchy checking we can 
>>pass a function pointer in and use the same basic system without the 
>>global DEBUG function pointer and still get what we want there. If we 
>>tried to use DEBUG for error reporting (as I think Ivan is suggesting) 
>>the calling function wouldn't get an error code, and thus check it's own 
>>error state until the first call in the chain and could potentially lose 
>>information. Having the specific error from the lowest point of failure 
>>seems much more useful than getting a less and less specific error from 
>>each funtion while propagating error codes.
>>    
>>
>
>I'm not sure I follow.  As currently used, I think a call to DEBUG() is
>always followed by returning an error code (although there might
>possibly be multiple calls to DEBUG() prior to returning, e.g. if we use
>it in the assertion checking code in place of the fprintf), although
>those error codes need to be more specific as well.
>
>  
>
What I mean is, if there are multiple calls to DEBUG prior to returning 
to the originating function then there are multiple error messages of 
varying specificity sitting around somewhere, assuming we even store 
them all and not just the last one. This isn't ideal for error 
reporting, but it is for debugging. Personally, again, I feel that gdb 
is far superior to any kind of debug system you can put in a library so 
I'd rather focus on proper error reporting, which DEBUG doesn't do in a 
reasonable way.

>>I know modifying every function in sepol to use a write_error like 
>>system is undesirable but libsemanage already has write_error used 
>>exclusively so going to DEBUG with it also seems undesirable. 
>>libsemanage already passes a handle which contains an error buffer which 
>>gives us thread safety and the ability to easily return errors in a way 
>>the client app can use them (semodule will probably just print them out, 
>>whereas the policy server will have to do more).
>>    
>>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.