lshw FTBFS: res_querydomain declared but not implemented

lshw FTBFS: res_querydomain declared but not implemented

[Isaac Dunham]

I've been trying to build lshw [1] with musl, and I ran into a few problems:
1: lshw uses __uint8_t (standard fixes work)
2: It wants GNU basename() (I added <libgen.h> and used -fpermissive)
3: It wants MAX_PATH from some header that doesn't have it: I added <limits.h>
4: It wants res_querydomain.
This does not show up until link time, since <resolv.h> declares it.
However, musl does not acually implement this function.

Currently, I've got a very hackish implementation that isn't fit to ship:
-it doesn't check for name == "machine."
-it doesn't handle domain == NULL (should use name, without any terminal ".")
-it does no error checking, on the assumption that res_query can handle that.

[1] http://ezix.org/project/wiki/HardwareLiSter

-- 
Isaac Dunham <idunham@lavabit.com>

Re: lshw FTBFS: res_querydomain declared but not implemented

[Szabolcs Nagy]

* Isaac Dunham <idunham@lavabit.com> [2012-12-30 21:59:31 -0800]:
> Currently, I've got a very hackish implementation that isn't fit to ship:

btw, what happened with strverscmp

Re: lshw FTBFS: res_querydomain declared but not implemented

[Rich Felker]

On Sun, Dec 30, 2012 at 09:59:31PM -0800, Isaac Dunham wrote:
> I've been trying to build lshw [1] with musl, and I ran into a few problems:

Have you sent any reports/patches upstream yet?

> 1: lshw uses __uint8_t (standard fixes work)

Indeed, this is just a bug in the app.

> 2: It wants GNU basename() (I added <libgen.h> and used -fpermissive)

I'm not sure how that would help. If it wants GNU semantics, it should
probably use a drop-in replacement for the function.

> 3: It wants MAX_PATH from some header that doesn't have it: I added <limits.h>

PATH_MAX is in limits.h. MAXPATHLEN is in sys/param.h (bogus header
full of random miscellaneous junk). I don't think I've ever heard of
MAX_PATH...

> 4: It wants res_querydomain.
> This does not show up until link time, since <resolv.h> declares it.
> However, musl does not acually implement this function.

And it seems to be completely undocumented how it's supposed to
work...

> Currently, I've got a very hackish implementation that isn't fit to ship:
> -it doesn't check for name == "machine."

What is special about "machine."?

> -it doesn't handle domain == NULL (should use name, without any terminal ".")

Seems easy enough to fix..

> -it does no error checking, on the assumption that res_query can handle that.

Seems fine.

BTW a full name can never be longer than 256 bytes (including null
termination), so you can do the concatenation on the stack in a
fixed-size array. You'll need to generate your own error if the
combined length would exceed the max.

Rich

Re: lshw FTBFS: res_querydomain declared but not implemented

[Isaac Dunham]

On Mon, 31 Dec 2012 13:06:53 -0500
Rich Felker <dalias@aerifal.cx> wrote:

> On Sun, Dec 30, 2012 at 09:59:31PM -0800, Isaac Dunham wrote:
> > I've been trying to build lshw [1] with musl, and I ran into a few problems:
> 
> Have you sent any reports/patches upstream yet?

I figured I'd get it to compile and see how it runs first.

<snip>

> > 3: It wants MAX_PATH from some header that doesn't have it: I added <limits.h>
> 
> PATH_MAX is in limits.h. MAXPATHLEN is in sys/param.h (bogus header
> full of random miscellaneous junk). I don't think I've ever heard of
> MAX_PATH...
Sorry, I meant PATH_MAX.

> > 4: It wants res_querydomain.
> > This does not show up until link time, since <resolv.h> declares it.
> > However, musl does not acually implement this function.
> 
> And it seems to be completely undocumented how it's supposed to
> work...
Call res_query with name as "name.domain". It's described in the linux-dev manpages. 
> > Currently, I've got a very hackish implementation that isn't fit to ship:
> > -it doesn't check for name == "machine."
> 
> What is special about "machine."?

That was a bad example; I meant "Doesn't check for a terminal '.'"

> > -it does no error checking, on the assumption that res_query can handle that.
> 
> Seems fine.
> 
> BTW a full name can never be longer than 256 bytes (including null
> termination), so you can do the concatenation on the stack in a
> fixed-size array. You'll need to generate your own error if the
> combined length would exceed the max.

Ah, thanks.

-- 
Isaac Dunham <idunham@lavabit.com>

[PATCH] Re: strverscmp (Was: Re: lshw FTBFS: res_querydomain...)

[Isaac Dunham]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

On Mon, 31 Dec 2012 13:44:18 +0100
Szabolcs Nagy <nsz@port70.net> wrote:

> 
> * Isaac Dunham <idunham@lavabit.com> [2012-12-30 21:59:31 -0800]:
> > Currently, I've got a very hackish implementation that isn't fit to ship:
> 
> btw, what happened with strverscmp

I had been waiting untill someone commented one way or the other on the last version of the standalone test version I sent.

But here's the patch.
-- 
Isaac Dunham <idunham@lavabit.com>

[-- Attachment #2: strverscmp.diff --]
[-- Type: text/x-diff, Size: 1189 bytes --]

commit ddf8e4a8099535b61fa7baaa7fae35e18ccf24ae
Author: Isaac Dunham <idunham@lavabit.com>
Date:   Mon Dec 31 12:38:36 2012 -0800

    Fix strverscmp.
    
    Disagrees with glibc by saying that 00 < 009, but that's a GNU bug.

diff --git a/src/string/strverscmp.c b/src/string/strverscmp.c
index 7054967..8f3f11f 100644
--- a/src/string/strverscmp.c
+++ b/src/string/strverscmp.c
@@ -1,7 +1,41 @@
+#define _GNU_SOURCE
+#include <ctype.h>
 #include <string.h>
 
 int strverscmp(const char *l, const char *r)
 {
-	/* FIXME */
-	return strcmp(l, r);
+	int haszero=1;
+	while (*l && *r && l[0]==r[0]){
+		if (l[0]=='0'){
+			if (haszero==1) {
+				haszero=0;
+			}
+		} else if (isdigit(l[0])) {
+			if (haszero==1) {
+				haszero=2;
+			}
+		} else {
+			haszero=1;
+		}
+		l++; r++;
+	}
+	if (haszero==1 && (l[0]=='0' || r[0]=='0')) {
+		haszero=0;
+	}
+	if ((isdigit(l[0]) && isdigit(r[0]) ) && haszero) {
+		int lenl=0, lenr=0, firstl=l[0], firstr=r[0];
+		while (isdigit(l++[0]) ) {
+			lenl++;
+		}
+		while (isdigit(r++[0]) ) {
+			lenr++;
+		}
+		if (lenl==lenr) {
+			return (firstl -  firstr);
+		} else {
+			return (lenl - lenr);
+		}
+	} else {
+		return (l[0] -  r[0]);
+	}
 }