* Carey Evans <[EMAIL PROTECTED]> [080610 06:34]:
> This bug is not about the Debian packaging of reprepro, but about
> compiling the upstream source on a non-Linux system.

Thanks for testing reprepro there. But please note reprepro is targeted
for systems using glibc or other compatible ones having all the gnu
extensions I like to use, as I deem reprepro seldom useful outside Debian
systems.
I'm willing to incorporate changes increasing portability outside of
that range, unless they make the code uglier or more fragile (or they
can be easily worked around).

> - A number of the files use malloc() and free() without including
> <stdlib.h>. The AIX C library is careful only to define these where
> the various standards say they should be found. I haven't provided a
> patch for this one.

Thanks for finding this. Should be fixed in CVS now.

> - The last parameter for execl() should be (char*)NULL, not just NULL,
> in case char* is a different size to whatever NULL resolves to. GCC
> 4.3 warns about this on AIX.

What is NULL there? I'm assuming NULL is (void)0 (and not simply 0).
Does compiling with "-DNULL=(void*)0" help?

> - AIX 5.3 doesn't provide O_NOFOLLOW. I most cases, this is combined
> with O_EXCL which seems to be redundant, and I've removed it; in
> donefile.c I've taken the potential security exposure and not used it.
> You might wish to define it to 0 instead.

I think that can also easily worked around by just adding -DO_NOFOLLOW=0
to CPPFLAGS.

> - AIX 5.3 doesn't have <endian.h>, but does get the BSD-ish
> BYTE_ORDER, BIG_ENDIAN and LITTLE_ENDIAN macros if you include
> <sys/param.h> and/or <sys/types.h>. I haven't included a patch for
> configure.ac, etc., to get them to detect HAVE_ENDIAN_H on Linux, but
> it should be trivial. Alternatively, there's AC_C_BIGENDIAN.

Hm, I'll have to take a look into these. Otherwise adding a file
endian.h to the source which #defines them to their BSD counterparts
should be easy. (perhaps I'll go the AC_C_BIGENDIAN route)

> - AIX 5.3 doesn't have vasnprintf (or dprintf). I've removed
> vmprintf(), changed formaterror to use snprintf with a static buffer
> that is much larger than anything it will have to hold, and changed
> mprintf() and dprintf() to call vsnprintf twice, as shown in the GNU
> libc manual. I figure that there's no point making dprintf() use
> vasprintf(), because they're both GNU libc extensions.

> - AIX doesn't have getopt_long, but I've compiled against libiberty from GCC.

Aren't vasnprintf and dprintf in libiberty, too? At least vasnprintf I
would have expected there.

> - _D_EXACT_NAMELEN is a GNU extension. I just use strlen(r->d_name) if
> it isn't defined.

Well, this could be fixed with a -D, too. But I think that is garanteed
to be an #define and it's only three lines in an header, so I added
that.

> - I don't check zlibCompileFlags() when using zlib 1.1, which is what
> I have available.

Sorry, support for older zlib was removed 2007-11-18.
Does it really produce correct .gz files when you just prevent the
safety guard against too old versions (At least I an hardly imagine
they have an gz header)?

Hochachtungsvoll,
        Bernhard R. Link
-- 
"Never contain programs so few bugs, as when no debugging tools are available!"
        Niklaus Wirth



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to