Date: Thu, 12 May 2011 18:45:22 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-stable@freebsd.org, joerg_surmann <joerg_surmann@snafu.de> Subject: Re: can't update libzip-0.9.3 to libzip-0.10 Message-ID: <20110512180918.W58178@sola.nimnet.asn.au> In-Reply-To: <20110512065945.GA55199@icarus.home.lan> References: <4DCB7962.6090706@snafu.de> <20110512061312.GA54574@icarus.home.lan> <4DCB81EF.2080104@snafu.de> <20110512065945.GA55199@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 11 May 2011, Jeremy Chadwick wrote:
> On Thu, May 12, 2011 at 08:45:03AM +0200, joerg_surmann wrote:
> > Hey Jeremy,
> >
> > Ok i'll put the files in a attachment
> > on the end from this email.
>
> [...snip...]
> [attachment: zipconf.h]
>
> Oh dear. I'm not sure what to make of this:
>
> > #ifndef _HAD_ZIPCONF_H
> > #define _HAD_ZIPCONF_H
> >
> > /*
> > zipconf.h -- platform specific include file
> >
> > This file was generated automatically by ./make_zipconf.sh
> > based on ../config.h.
> > */
> >
> > #define LIBZIP_VERSION "0.10"
> > #define LIBZIP_VERSION_MAJOR 0
> > #define LIBZIP_VERSION_MINOR 10
> > #define LIBZIP_VERSION_MICRO 0
> >
> > #include <inttypes.h>
> >
> > typedef signed char int8_t;
> > #define ZIP_INU8_MAX SCHAR_MAX
> >
> > typedef unsigned char uint8_t;
> > #define ZIP_?INU8_MAX ?CHAR_MAX
> >
> > typedef shor? int16_t;
> > #define ZIP_INU16_MIN ?CHAR_MIN
> > #define ZIP_INU16_MAX ?CHAR_MAX
> >
> > typedef unsigned shor? uint16_t;
> > #define ZIP_?INU16_MAX ?CHAR_MAX
> >
> > typedef in? int32_t;
> > #define ZIP_INU32_MIN ?CHAR_MIN
> > #define ZIP_INU32_MAX ?CHAR_MAX
> >
> > typedef unsigned in? uint32_t;
> > #define ZIP_?INU32_MAX ?CHAR_MAX
> >
> > typedef long int64_t;
> > #define ZIP_INU64_MIN SLONG_MIN
> > #define ZIP_INU64_MAX SLONG_MAX
> >
> > typedef unsigned long uint64_t;
> > #define ZIP_?INU64_MAX ?LONG_MAX
> >
> >
> > #endif /* zipconf.h */
>
> All of these values have a "?" injected in them, at seemingly randomly
> places. This is the problem, and why the C compiler is throwing errors.
Indeed, but not really '?' and not so random. Viewing zipconf.h in less
shows control characters as <hexchars> for the section of concern:
=======
typedef unsigned char uint8_t;
#define ZIP_<DA>INU8_MAX <DA>CHAR_MAX
typedef shor<DF> int16_t;
#define ZIP_INU16_MIN <DA>CHAR_MIN
#define ZIP_INU16_MAX <DA>CHAR_MAX
typedef unsigned shor<DF> uint16_t;
#define ZIP_<DA>INU16_MAX <DA>CHAR_MAX
typedef in<DF> int32_t;
#define ZIP_INU32_MIN <DA>CHAR_MIN
#define ZIP_INU32_MAX <DA>CHAR_MAX
typedef unsigned in<DF> uint32_t;
#define ZIP_<DA>INU32_MAX <DA>CHAR_MAX
typedef long int64_t;
#define ZIP_INU64_MIN SLONG_MIN
#define ZIP_INU64_MAX SLONG_MAX
typedef unsigned long uint64_t;
#define ZIP_<DA>INU64_MAX <DA>LONG_MAX
=======
In ISO-8859-1 at least, <DF> is that German character that looks rather
like a capital B in running writing (perhaps it's some sort of 't', as
in short and int?), and the <DA> looks like a capital U with a single
dot above, initially not easy to distinguish from cap U (appearing so
alike to eg 'ULONG*' or 'UCHAR*' that I missed it on first glance)
> I don't know how or why this is happening. There could be many things
> going on that might explain it. Worst case would be odd/awkward
> hardware failure (bad RAM would show something like this), corrupt
> filesystem, a disk going bad silently ("bit rot"), etc..
This one seems far too non-random to be a hardware issue artifact.
> My initial guess -- because this port uses a GNU autoconf script -- is
> that it's obtaining the types for things incorrectly.
>
> Are you using any sort of LC_CTYPE or LANG setting in your dotfiles that
> gets propagated to the root environment (during su, sudo, etc.)? I see
> that you're in .de which is why I ask.
I expect that's likely much closer to the mark.
> I've attached a zipconf.h file from my system. You can compare the
> differences; it should be obvious. My system does not have "?"
> characters injected into the typedefs, but more importantly (and this is
> indeed important!), the types it detects/uses are completely different.
>
> I'm not sure what's going on with your system, but it almost implies
> that you have a separate set of include files that are "trumping" or
> "overriding" the FreeBSD base system defaults.
Quite likely language related, but I've no idea HOW that could happen?
cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110512180918.W58178>