Re: Question about the code
On 2012-10-08, Ted Unangst t...@tedunangst.com wrote: On Mon, Oct 08, 2012 at 13:59, David Coppa wrote: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=473 Fixed in trunk. Maybe update OpenBSD's code ? Here's a diff for our tree: I'm not the one doing future imports, but it seems it'd be easier to just import the next version. We don't need to fix this right now, do we? agreed, it's not enabled yet, and for something minor like this it's not really worth the additional merging when it is time to update.
Re: Question about the code
Le 07/10/2012 14:58, rustyBSD a écrit : On 10/07/12 13:41, Theo de Raadt wrote: If you type unbound into google, you will see that this is upstream code that is incorporated into OpenBSD. Therefore, you should really contact that project. Already done https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=473 Fixed in trunk. Maybe update OpenBSD's code ?
Re: Question about the code
On Mon, 08 Oct 2012, rustyBSD wrote:
Le 07/10/2012 14:58, rustyBSD a ?crit :
On 10/07/12 13:41, Theo de Raadt wrote:
If you type unbound into google, you will see that
this is upstream code that is incorporated into OpenBSD.
Therefore, you should really contact that project.
Already done
https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=473
Fixed in trunk.
Maybe update OpenBSD's code ?
Here's a diff for our tree:
Index: drill/drill_util.c
===
RCS file: /cvs/src/usr.sbin/unbound/ldns/drill/drill_util.c,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 drill_util.c
--- drill/drill_util.c 23 Aug 2012 22:28:45 - 1.1.1.2
+++ drill/drill_util.c 8 Oct 2012 11:53:27 -
@@ -13,7 +13,7 @@
#include errno.h
-static size_t
+static int
read_line(FILE *input, char *line, size_t len)
{
size_t i;
@@ -71,6 +71,7 @@ read_key_file(const char *filename, ldns
}
}
printf(;; Number of trusted keys: %d\n, key_count);
+ fclose(input_file);
if (key_count 0) {
return LDNS_STATUS_OK;
} else {
Index: drill/work.c
===
RCS file: /cvs/src/usr.sbin/unbound/ldns/drill/work.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 work.c
--- drill/work.c26 Mar 2012 18:08:26 - 1.1.1.1
+++ drill/work.c8 Oct 2012 11:53:27 -
@@ -177,21 +177,7 @@ read_hex_buffer(char *filename)
uint8_t *wire;
size_t wiresize;
ldns_buffer *result_buffer = NULL;
-
- FILE *fp = NULL;
-
- if (strncmp(filename, -, 2) != 0) {
- fp = fopen(filename, r);
- } else {
- fp = stdin;
- }
-
- if (fp == NULL) {
- perror();
- warning(Unable to open %s, filename);
- return NULL;
- }
-
+
wire = xmalloc(LDNS_MAX_PACKETLEN);
wiresize = packetbuffromfile(filename, wire);
@@ -199,7 +185,7 @@ read_hex_buffer(char *filename)
result_buffer = LDNS_MALLOC(ldns_buffer);
ldns_buffer_new_frm_data(result_buffer, wire, wiresize);
ldns_buffer_set_position(result_buffer,
ldns_buffer_capacity(result_buffer));
-
+
xfree(wire);
return result_buffer;
}
Re: Question about the code
On Mon, Oct 08, 2012 at 13:59, David Coppa wrote: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=473 Fixed in trunk. Maybe update OpenBSD's code ? Here's a diff for our tree: I'm not the one doing future imports, but it seems it'd be easier to just import the next version. We don't need to fix this right now, do we?
Re: Question about the code
Hi, it's about src/usr.sbin/unbound/ldns/drill/work.c at line 184: What is the 'fp' FILE used for ? Here - if I'm not mistaken - we fopen() filename, and that's it. We don't use the 'fp' variable, and we never fclose() it. If you type unbound into google, you will see that this is upstream code that is incorporated into OpenBSD. Therefore, you should really contact that project.
Re: Question about the code
On 10/07/12 13:41, Theo de Raadt wrote: If you type unbound into google, you will see that this is upstream code that is incorporated into OpenBSD. Therefore, you should really contact that project. Already done
Question about the code
Hi, it's about src/usr.sbin/unbound/ldns/drill/work.c at line 184: What is the 'fp' FILE used for ? Here - if I'm not mistaken - we fopen() filename, and that's it. We don't use the 'fp' variable, and we never fclose() it. Am I wrong ? Thanks
Re: Question about the code
On Sat, Oct 06, 2012 at 10:11:20PM +0200, rustyBSD wrote: Hi, it's about src/usr.sbin/unbound/ldns/drill/work.c at line 184: What is the 'fp' FILE used for ? Here - if I'm not mistaken - we fopen() filename, and that's it. We don't use the 'fp' variable, and we never fclose() it. Am I wrong ? Thanks Good catch. There's obviously some unfinished refactoring. The file handling got into packetbufffromfile, all other callers got it... This one was left stranded out. What's funny, though, is that the code in packetbufffromfile is worse than the code you're talking about, especially the error message doesn't mention the filename...
