W_ERROR_HAVE_NO_MEMORY and friends

Michael Adam obnox at samba.org
Tue Jun 5 05:04:30 MDT 2012


Hi Andrew,

Andrew Bartlett wrote:
> I just want to re-state my position more clearly, to avoid being
> misunderstood:
> 
> On Wed, 2012-05-30 at 21:25 +1000, Andrew Bartlett wrote:
> 
> > The one thing I would say is that our coding guidelines should reflect
> > the bulk of the recent, modern code we write and work with.  That is, I
> > honestly don't read our style guide often, but I'm very much influenced
> > by the style of the code I work on.  
> 
> > At this point I am willing to be convinced either way
> 
> As I've said elsewhere, I was surprised by these macros when I first saw
> them.  I would prefer that if we keep them, that the macros that do
> return, but don't say RETURN or assert be modified to do so. 
> 
> If we are of a view to remove them, I would like a substantial portion
> of our code to be modified to reflect that, so that our code is
> consistent with our style guide.  I'm of course happy to review changes
> to areas for which I'm familiar. 
> 
> I hope this clarifies my position,

  From this I take it that you would not raise veto against banning
the use of these macros. I am not certain that it would be good
to make it mandatory to change large portions of existing code to
adhere to these rules.

My preference would be to:

1) add the rule to ban them,
2) to review future patches for adhering to the rule
3) and to change existing code as we move along and touch it
   rather than doing a distracting mandatory tour de force now.

Given that Kai withdrew his veto, can we assume that there is no
veto against banning these flow-changing macros?
Would the above compromise be ok for everybody?

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120605/18fcf385/attachment.pgp>


More information about the samba-technical mailing list