BIND 10 #782: Implement cryptographic API using Botan

BIND 10 Development do-not-reply at isc.org
Fri May 20 07:03:39 UTC 2011


#782: Implement cryptographic API using Botan
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  hanfeng
  stephen                            |                Status:  closed
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20110531
                   Priority:  major  |            Resolution:  fixed
                  Component:         |             Sensitive:  0
  Unclassified                       |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  3.0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:  tsig   |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 (Happen to notice the discussion for this ticket while I cleaned up
 my inbox...)

 I hesitate to intrude into discussions between the reviewer and the
 implementer (especially when it's seemingly over), but I quite
 strongly oppose the way of using macro in crypto_unittests.  I
 generally believe in the Stroustrup's rule about macro: "Do not use
 them if you do not have to.  Almost every macro demonstrates a flaw in
 the programming language, in the program, or in the programmer".

 And, I don't see any reason why we *have to* use macro here.
 Apparently the intent is to avoid some repeated pattern, but I can
 easily think of alternative ways to achieve that goal without using
 macro.  I'm attaching an example alternative.  Whether this one is
 simpler may be a matter of opinion, but if it's a matter of opinion it
 should be more than sufficient to prefer the one that doesn't rely on
 macro.

 Also, the fact that the macro is used in a test file isn't
 sufficiently convincing to me as an excuse to use it.  It's certainly
 less harmful than using macro in header files, but it could still bite
 ourselves in a surprising way.  In addition, I personally think it's
 generally important to keep our sources clean as much as possible so
 that when we use evil practices such as macro or cast the points where
 they are used are more clearly visible and we can be careful about
 them (for example, it should be better if we can only have a handful
 of results of 'grep #define' on our source tree).  An easy use of
 macro will make the situation worse.

 So I seriously ask you to reconsider the use of macro before merging.
 I'm not necessarily pushing the attached patch, but if the attached
 patch is acceptable to you, I'd suggest applying it.

-- 
Ticket URL: <http://bind10.isc.org/ticket/782#comment:21>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list