From des at des.no  Tue Apr  9 13:05:56 2013
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Tue, 09 Apr 2013 15:05:56 +0200
Subject: [ldns-users] Missing or incorrect prototypes
In-Reply-To: <51472641.20906@nlnetlabs.nl> (Willem Toorop's message of "Mon,
 18 Mar 2013 15:35:45 +0100")
References: <86liapp7j9.fsf@ds4.des.no> <86a9r3c3jx.fsf@ds4.des.no>
 <8638wvc3bh.fsf@ds4.des.no> <51472641.20906@nlnetlabs.nl>
Message-ID: <8661zvzwej.fsf@ds4.des.no>

Willem Toorop <willem at nlnetlabs.nl> writes:
> Your patches are committed to trunk (Though unstaticized
> ldns_dname_compare_v, because it is used in dnssec_sign too ;).

It still needs a prototype:

Index: ldns/dname.h
===================================================================
--- ldns/dname.h	(revision 3837)
+++ ldns/dname.h	(working copy)
@@ -150,6 +150,7 @@
  * \return -1 if dname1 comes before dname2, 1 if dname1 comes after dname2, and 0 if they are equal.
  */
 int ldns_dname_compare(const ldns_rdf *dname1, const ldns_rdf *dname2);
+int ldns_dname_compare_v(const void *, const void *);
 
 /**
  * Checks whether the dname matches the given wildcard

BTW, including argument names in prototypes is a bad habit - it pollutes
the application namespace.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no



From des at des.no  Tue Apr  9 13:41:38 2013
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Tue, 09 Apr 2013 15:41:38 +0200
Subject: [ldns-users] b64_ntop() / b64_pton() nit
Message-ID: <86y5cryg6l.fsf@ds4.des.no>

This has no practical significance, since you will probably never come
across a system that has b64_pton() but not b64_ntop() (or the other way
around), but the conditionals in configure.ac got switched around:

Index: configure.ac
===================================================================
--- configure.ac	(revision 3837)
+++ configure.ac	(working copy)
@@ -637,7 +637,7 @@
 extern "C" {
 #endif
 
-#ifndef B64_PTON
+#ifndef B64_NTOP
 int ldns_b64_ntop(uint8_t const *src, size_t srclength,
 	 	  char *target, size_t targsize);
 /**
@@ -648,8 +648,8 @@
 {
 	return ((((srcsize + 2) / 3) * 4) + 1);
 }
-#endif /* !B64_PTON */
-#ifndef B64_NTOP
+#endif /* !B64_NTOP */
+#ifndef B64_PTON
 int ldns_b64_pton(char const *src, uint8_t *target, size_t targsize);
 /**
  * calculates the size needed to store the result of ldns_b64_pton
@@ -659,7 +659,7 @@
 {
 	return (((((srcsize + 3) / 4) * 3)) + 1);
 }
-#endif /* !B64_NTOP */
+#endif /* !B64_PTON */
 
 #ifndef HAVE_SLEEP
 /* use windows sleep, in millisecs, instead */

DES
-- 
Dag-Erling Sm?rgrav - des at des.no



From des at des.no  Tue Apr  9 13:56:29 2013
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Tue, 09 Apr 2013 15:56:29 +0200
Subject: [ldns-users] b64_ntop() / b64_pton() nit
In-Reply-To: <86y5cryg6l.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?=
 =?utf-8?Q?rav=22's?= message of "Tue, 09 Apr 2013 15:41:38 +0200")
References: <86y5cryg6l.fsf@ds4.des.no>
Message-ID: <86txnfyfhu.fsf@ds4.des.no>

Dag-Erling Sm?rgrav <des at des.no> writes:
> This has no practical significance, since you will probably never come
> across a system that has b64_pton() but not b64_ntop() (or the other way
> around), but the conditionals in configure.ac got switched around:

Come to think of it, they have no effect at all since the actual
predicates are HAVE_B64_NTOP and HAVE_B64_PTON, not B64_NTOP and
B64_PTON; the conditions will always be true.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no



From willem at nlnetlabs.nl  Tue Apr  9 14:21:49 2013
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Tue, 09 Apr 2013 16:21:49 +0200
Subject: [ldns-users] Missing or incorrect prototypes
In-Reply-To: <8661zvzwej.fsf@ds4.des.no>
References: <86liapp7j9.fsf@ds4.des.no> <86a9r3c3jx.fsf@ds4.des.no>
 <8638wvc3bh.fsf@ds4.des.no> <51472641.20906@nlnetlabs.nl>
 <8661zvzwej.fsf@ds4.des.no>
Message-ID: <516423FD.40102@nlnetlabs.nl>

Hi Dag-Erling,

Op 09-04-13 15:05, Dag-Erling Sm?rgrav schreef:
> Willem Toorop <willem at nlnetlabs.nl> writes:
> It still needs a prototype:

This helper function is not intended for use by the public.
It has no place in the public API.

> BTW, including argument names in prototypes is a bad habit - it pollutes
> the application namespace.

Who says so?
It has documentational value. It indicates the meaning of what is expected.

-- Willem


From willem at nlnetlabs.nl  Tue Apr  9 14:52:21 2013
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Tue, 09 Apr 2013 16:52:21 +0200
Subject: [ldns-users] b64_ntop() / b64_pton() nit
In-Reply-To: <86txnfyfhu.fsf@ds4.des.no>
References: <86y5cryg6l.fsf@ds4.des.no> <86txnfyfhu.fsf@ds4.des.no>
Message-ID: <51642B25.2030605@nlnetlabs.nl>

Op 09-04-13 15:56, Dag-Erling Sm?rgrav schreef:
> Come to think of it, they have no effect at all since the actual
> predicates are HAVE_B64_NTOP and HAVE_B64_PTON, not B64_NTOP and
> B64_PTON; the conditions will always be true.

Indeed! A more than 8 years old error.
ldns uses its own ldns_b(32|64)_(pton|ntop) always, regardless the
availability of b(32|64)_(pton|ntop). I'll prepare a correction...

Thanks!
-- Willem



From des at des.no  Tue Apr  9 16:39:52 2013
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Tue, 09 Apr 2013 18:39:52 +0200
Subject: [ldns-users] Missing or incorrect prototypes
In-Reply-To: <516423FD.40102@nlnetlabs.nl> (Willem Toorop's message of "Tue,
 09 Apr 2013 16:21:49 +0200")
References: <86liapp7j9.fsf@ds4.des.no> <86a9r3c3jx.fsf@ds4.des.no>
 <8638wvc3bh.fsf@ds4.des.no> <51472641.20906@nlnetlabs.nl>
 <8661zvzwej.fsf@ds4.des.no> <516423FD.40102@nlnetlabs.nl>
Message-ID: <86li8rac9z.fsf@ds4.des.no>

Willem Toorop <willem at nlnetlabs.nl> writes:
> Dag-Erling Sm?rgrav <des at des.no> writes:
> > It still needs a prototype:
> This helper function is not intended for use by the public.  It has no
> place in the public API.

Then provide a prototype in a separate header which is only used
internally.

> > BTW, including argument names in prototypes is a bad habit - it
> > pollutes the application namespace.
> Who says so?

The C standard.

C doesn't have as many distinct name spaces as you'd like, so using a
particular identifier as an argument name in a header file restricts
what a source file that includes that header file can use that
identifier for.  This is why people do stupid things like:

foo.c: int foo(int a, int b) { /* ... */ }
foo.h: int foo(int _a, int _b);

so foo.h won't "steal" a and b from the application, but this just
replaces one error with another (_a and _b are in a namespace which is
reserved for the implementation).  It is better to just leave out the
name entirely.

> It has documentational value. It indicates the meaning of what is
> expected.

1) You already have comments documenting the arguments.

2) Your users shouldn't have to refer to the headers anyway.  That's
   what man pages are for.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no



From paul at nohats.ca  Tue Apr  9 19:06:45 2013
From: paul at nohats.ca (Paul Wouters)
Date: Tue, 9 Apr 2013 15:06:45 -0400 (EDT)
Subject: [ldns-users] Missing or incorrect prototypes
In-Reply-To: <86li8rac9z.fsf@ds4.des.no>
References: <86liapp7j9.fsf@ds4.des.no> <86a9r3c3jx.fsf@ds4.des.no>
 <8638wvc3bh.fsf@ds4.des.no> <51472641.20906@nlnetlabs.nl>
 <8661zvzwej.fsf@ds4.des.no> <516423FD.40102@nlnetlabs.nl>
 <86li8rac9z.fsf@ds4.des.no>
Message-ID: <alpine.LFD.2.10.1304091503220.3283@bofh.nohats.ca>

On Tue, 9 Apr 2013, Dag-Erling Sm?rgrav wrote:

> Willem Toorop <willem at nlnetlabs.nl> writes:
>> Dag-Erling Sm?rgrav <des at des.no> writes:
>>> It still needs a prototype:
>> This helper function is not intended for use by the public.  It has no
>> place in the public API.
>
> Then provide a prototype in a separate header which is only used
> internally.

Or better yet, see if you can make the function static?

> The C standard.
>
> C doesn't have as many distinct name spaces as you'd like, so using a
> particular identifier as an argument name in a header file restricts
> what a source file that includes that header file can use that
> identifier for.  This is why people do stupid things like:
>
> foo.c: int foo(int a, int b) { /* ... */ }
> foo.h: int foo(int _a, int _b);
>
> so foo.h won't "steal" a and b from the application, but this just
> replaces one error with another (_a and _b are in a namespace which is
> reserved for the implementation).  It is better to just leave out the
> name entirely.

Interesting. I should look into this....

> 2) Your users shouldn't have to refer to the headers anyway.  That's
>   what man pages are for.

If only I was allowed to delete every binary and header file that has
no man page, or a man page refering to the info pages, or other man page
placeholders, along with binaries that do not have -h, --help, -v,
--version

Paul


From des at des.no  Tue Apr  9 19:38:01 2013
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Tue, 09 Apr 2013 21:38:01 +0200
Subject: [ldns-users] Missing or incorrect prototypes
In-Reply-To: <alpine.LFD.2.10.1304091503220.3283@bofh.nohats.ca> (Paul
 Wouters's message of "Tue, 9 Apr 2013 15:06:45 -0400 (EDT)")
References: <86liapp7j9.fsf@ds4.des.no> <86a9r3c3jx.fsf@ds4.des.no>
 <8638wvc3bh.fsf@ds4.des.no> <51472641.20906@nlnetlabs.nl>
 <8661zvzwej.fsf@ds4.des.no> <516423FD.40102@nlnetlabs.nl>
 <86li8rac9z.fsf@ds4.des.no>
 <alpine.LFD.2.10.1304091503220.3283@bofh.nohats.ca>
Message-ID: <86bo9n8pgm.fsf@ds4.des.no>

Paul Wouters <paul at nohats.ca> writes:
> Dag-Erling Sm?rgrav <des at des.no> writes:
> > Willem Toorop <willem at nlnetlabs.nl> writes:
> > > This helper function is not intended for use by the public.  It
> > > has no place in the public API.
> > Then provide a prototype in a separate header which is only used
> > internally.
> Or better yet, see if you can make the function static?

That just brings us back where we started.  The function in question is
defined in one translation unit and used in another, but is not intended
for use outside ldns.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no



From jkomissa at cisco.com  Tue Apr  9 20:20:48 2013
From: jkomissa at cisco.com (Jan Komissar (jkomissa))
Date: Tue, 9 Apr 2013 20:20:48 +0000
Subject: [ldns-users] Missing or incorrect prototypes
In-Reply-To: <alpine.LFD.2.10.1304091503220.3283@bofh.nohats.ca>
Message-ID: <F4FBC9CB390A694A88933F40B4EC480403962688@xmb-aln-x12.cisco.com>

Some IDEs show the parameters of a function when you type it (see picture
from Eclipse). It is very useful to know the order and type of parameters
in the context of writing code, so you don't have to distract yourself by
looking up that information.


And, Dag-Erling, Can you show me an example (without "#define a") where
the declaration "int foo(int a);" steals "a" from the application's name
space. I wasn't able to come up with an example on my own.

Cheers,

Jan.


On 4/9/13 3:06 PM, "Paul Wouters" <paul at nohats.ca> wrote:

>On Tue, 9 Apr 2013, Dag-Erling Sm?rgrav wrote:
>
>> Willem Toorop <willem at nlnetlabs.nl> writes:
>>> Dag-Erling Sm?rgrav <des at des.no> writes:
>>>> It still needs a prototype:
>>> This helper function is not intended for use by the public.  It has no
>>> place in the public API.
>>
>> Then provide a prototype in a separate header which is only used
>> internally.
>
>Or better yet, see if you can make the function static?
>
>> The C standard.
>>
>> C doesn't have as many distinct name spaces as you'd like, so using a
>> particular identifier as an argument name in a header file restricts
>> what a source file that includes that header file can use that
>> identifier for.  This is why people do stupid things like:
>>
>> foo.c: int foo(int a, int b) { /* ... */ }
>> foo.h: int foo(int _a, int _b);
>>
>> so foo.h won't "steal" a and b from the application, but this just
>> replaces one error with another (_a and _b are in a namespace which is
>> reserved for the implementation).  It is better to just leave out the
>> name entirely.
>
>Interesting. I should look into this....
>
>> 2) Your users shouldn't have to refer to the headers anyway.  That's
>>   what man pages are for.
>
>If only I was allowed to delete every binary and header file that has
>no man page, or a man page refering to the info pages, or other man page
>placeholders, along with binaries that do not have -h, --help, -v,
>--version
>
>Paul
>_______________________________________________
>ldns-users mailing list
>ldns-users at open.nlnetlabs.nl
>http://open.nlnetlabs.nl/mailman/listinfo/ldns-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: default.png
Type: image/png
Size: 4264 bytes
Desc: default.png
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20130409/b23d41e6/attachment.png>

From des at des.no  Wed Apr 10 09:10:56 2013
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Wed, 10 Apr 2013 11:10:56 +0200
Subject: [ldns-users] b64_ntop() / b64_pton() nit
In-Reply-To: <51642B25.2030605@nlnetlabs.nl> (Willem Toorop's message of "Tue, 
 09 Apr 2013 16:52:21 +0200")
References: <86y5cryg6l.fsf@ds4.des.no> <86txnfyfhu.fsf@ds4.des.no>
 <51642B25.2030605@nlnetlabs.nl>
Message-ID: <86y5cqpx7j.fsf@ds4.des.no>

Willem Toorop <willem at nlnetlabs.nl> writes:
> ldns uses its own ldns_b(32|64)_(pton|ntop) always, regardless the
> availability of b(32|64)_(pton|ntop). I'll prepare a correction...

Waitasec, I have more.

b64* and b32* are treated differently.  The former are handled directly
in configure.ac -> config.h, while the latter are handled in util.h.  In
addition, the code is always compiled, regardless of whether it will be
used.

The attached patch

 - moves the b64* prototypes from configure.ac to util.h.in

 - staticizes the *_ar() functions, which are only used internally

 - makes everything in b{32,64}_{ntop,pton}.c except the inclusion of
   config.h conditional on HAVE_B{32,64}_{NTOP,PTON}.

I would also suggest either removing the assertions in these four files,
or replacing the homegrown Assert() macro with the standard assert(),
which can be disabled by defining NDEBUG.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldns-ntop-pton.diff
Type: text/x-patch
Size: 5914 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20130410/2ccc0940/attachment.bin>

From des at des.no  Wed Apr 10 09:15:09 2013
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Wed, 10 Apr 2013 11:15:09 +0200
Subject: [ldns-users] Missing or incorrect prototypes
In-Reply-To: <F4FBC9CB390A694A88933F40B4EC480403962688@xmb-aln-x12.cisco.com>
 (Jan Komissar's message of "Tue, 9 Apr 2013 20:20:48 +0000")
References: <F4FBC9CB390A694A88933F40B4EC480403962688@xmb-aln-x12.cisco.com>
Message-ID: <86txnepx0i.fsf@ds4.des.no>

"Jan Komissar (jkomissa)" <jkomissa at cisco.com> writes:
> And, Dag-Erling, Can you show me an example (without "#define a") where
> the declaration "int foo(int a);" steals "a" from the application's name
> space. I wasn't able to come up with an example on my own.

I'd have to construct one (or dig through svn logs to find a real-world
examples from ten years back).  It is easier to find examples of
argument names infringing on implementation namespace, such as the ever
popular "struct sockaddr_in *sin" which is a constraint violation if
<math.h> is in scope (and with certain compiler flags, gcc will
incorrectly complain even if when <math.h> isn't in scope).

DES
-- 
Dag-Erling Sm?rgrav - des at des.no



From dot at dotat.at  Wed Apr 10 10:00:27 2013
From: dot at dotat.at (Tony Finch)
Date: Wed, 10 Apr 2013 11:00:27 +0100
Subject: [ldns-users] Missing or incorrect prototypes
In-Reply-To: <8661zvzwej.fsf@ds4.des.no>
References: <86liapp7j9.fsf@ds4.des.no> <86a9r3c3jx.fsf@ds4.des.no>
 <8638wvc3bh.fsf@ds4.des.no> <51472641.20906@nlnetlabs.nl>
 <8661zvzwej.fsf@ds4.des.no>
Message-ID: <alpine.LSU.2.00.1304101041330.1311@hermes-2.csi.cam.ac.uk>

Dag-Erling Sm?rgrav <des at des.no> wrote:
>
> BTW, including argument names in prototypes is a bad habit - it pollutes
> the application namespace.

It mostly does not, because function prototype parameter lists are a
distinct scope. The most tricky aspect of identifiers in function
prototypes is that if you declare

  int foo(struct sockaddr_in *sin);

and struct sockaddr_in is not already declared, then the scope of the
struct sockaddr_in is just the function prototype, and is a different type
from every other struct sockaddr_in in the program.

Parameter names are not problematic provided they don't clash with macros.
Functions in the standard library can also have macro versions, which is
generally not a problem since the macro will only be expanded if it is
followed by an open round bracket. However it can cause amusement if you
try declaring function pointer paramaters like

  int abstract_io_thing(int getc(io_handle), void putc(io_handle, int));


ISO 9899:1999 section 6.2.1 Scopes of identifiers:

3 A label name is the only kind of identifier that has function scope. It
  can be used (in a goto statement) anywhere in the function in which it
  appears, and is declared implicitly by its syntactic appearance
  (followed by a : and a statement).

4 Every other identifier has scope determined by the placement of its
  declaration (in a declarator or type specifier). If the declarator or
  type specifier that declares the identifier appears outside of any block
  or list of parameters, the identifier has file scope, which terminates
  at the end of the translation unit. If the declarator or type specifier
  that declares the identifier appears inside a block or within the list
  of parameter declarations in a function definition, the identifier has
  block scope, which terminates at the end of the associated block. If the
  declarator or type specifier that declares the identifier appears within
  the list of parameter declarations in a function prototype (not part of
  a function definition), the identifier has function prototype scope,
  which terminates at the end of the function declarator. If an identifier
  designates two different entities in the same name space, the scopes
  might overlap. If so, the scope of one entity (the inner scope) will be
  a strict subset of the scope of the other entity (the outer scope).
  Within the inner scope, the identifier designates the entity declared in
  the inner scope; the entity declared in the outer scope is hidden (and
  not visible) within the inner scope.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

From jelte.jansen at sidn.nl  Fri Apr 19 14:27:26 2013
From: jelte.jansen at sidn.nl (Jelte Jansen)
Date: Fri, 19 Apr 2013 16:27:26 +0200
Subject: [ldns-users] 'example' tool: ldns-3597
Message-ID: <5171544E.8040000@sidn.nl>


Hi,

I needed something to rewrite a specific subset of types in
RFC3597-unknown-type syntax (e.g. TYPEXXX \# <hex data>) (In my
particular use-case i am signing something with ldns-signzone that has a
few old and exotic types which not all name servers, including NSD,
accept), so I wrote a little tool to do that; ldns-3597.

I *think* this could be part of the examples of ldns, and perhaps even
an optional feature in ldns-read-zone, but I'm not sure whether the
use-case is general enough.

Anyway, I've put up an initial version at

http://tjeb.nl/opendir/3597/ldns-3597.c

Jelte


From willem at nlnetlabs.nl  Tue Apr 23 15:12:01 2013
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Tue, 23 Apr 2013 17:12:01 +0200
Subject: [ldns-users] 'example' tool: ldns-3597
In-Reply-To: <5171544E.8040000@sidn.nl>
References: <5171544E.8040000@sidn.nl>
Message-ID: <5176A4C1.7050602@nlnetlabs.nl>

Hi Jelte,

Love the usefulness and modularity of having a separate ldns-3597 tool.
But, printing RR's in 3597 format is general enough to be included as a
feature in the library. We could add a flag for struct
ldns_output_format. Not sure yet whether it should just turn on type
3597 printing for all types or for specific types; The data attribute in
struct ldns_output_format could point to a RR-type bitmap...

-- Willem


Op 19-04-13 16:27, Jelte Jansen schreef:
> 
> Hi,
> 
> I needed something to rewrite a specific subset of types in
> RFC3597-unknown-type syntax (e.g. TYPEXXX \# <hex data>) (In my
> particular use-case i am signing something with ldns-signzone that has a
> few old and exotic types which not all name servers, including NSD,
> accept), so I wrote a little tool to do that; ldns-3597.
> 
> I *think* this could be part of the examples of ldns, and perhaps even
> an optional feature in ldns-read-zone, but I'm not sure whether the
> use-case is general enough.
> 
> Anyway, I've put up an initial version at
> 
> http://tjeb.nl/opendir/3597/ldns-3597.c
> 
> Jelte
> _______________________________________________
> ldns-users mailing list
> ldns-users at open.nlnetlabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users
>