tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Initial MirBSD support for pkgsrc



On Sun, Jan 23, 2011 at 02:01:55PM +0100, Benny Siegert wrote:
> On Fri, 21 Jan 2011, Alistair Crooks wrote:
> 
> >Can someone provide a definitive set of patches for MirBSD then, please?
> 
> I sent a three-part patch with extended descriptions to tech-pkg on Jan 
> 15. I consider this version to be "definitive". I can resend it if you 
> like.

No, I have the patches, and they are in the archive, but my impression
from the ensuing conversation (see attached) was that these were not
definitive.

Personally, I'd like there to be consensus amongst MirBSD developers
as to what the correct approach is, which is the reason for my
original question.

Thanks,
Alistair
--- Begin Message ---
Benny Siegert dixit:

>devel/bmake/files/unit-tests/modts: Using echo in the test is not
>       portable, as it may interpret backslash escapes, depending on
>       the shell. If mksh is used as the shell, it replaces \x by a
>       null byte. Replace echo by printf for the tests in this file to
>       avoid this.

Note that echo is the least portable, anyway, so this ought to go
in definitively, independent on your stance on this mkshâs expansion
(there are ways to prevent it, but not selected here).

>The libfetch patch fixes two compiler warnings (-Wformat), which would 
>otherwise make the build fail because -Werror is in effect:

On MirBSD, -Wformat is on to catch exactly this kind of errors, since
we pioneered a 64-bit time_t on an ILP32 platform years before NetBSDÂ.

>net/libfetch/files/ftp.c: On some operating systems (notably MirBSD), the
>       tm_year member in struct tm is a long, not an int. The package

This is wrong, itâs actually a time_t because some applications, most
notably GNU CVSâ configure script (via gnulib), depend on being able
to have a lossless round-trip conversion of any value of time_t to
struct tm and back.

>       tools already have support for this, libfetch does not. Here, use
>       a temporary variable to read in the year so the length is known.

This patch is correct, for int values of tm_year.

>net/libfetch/files/http.c: Same issue as above; cast tm_year to a long
>       before printing it.

-           tm.tm_year + 1900, tm.tm_hour, tm.tm_min, tm.tm_sec);
+           (long)tm.tm_year + 1900, tm.tm_hour, tm.tm_min, tm.tm_sec);

I think (long)(tm.tm_year + 1900) would be better. Or casting to int,
which can be changed to int64_t if pkgsrc is still around by then.
Casting to long involves quite some overhead on current LP64 platforms.

bye,
//mirabilos
-- 
  âHaving a smoking section in a restaurant is like having
          a peeing section in a swimming pool.â
                                                -- Edward Burr

--- End Message ---


Home | Main Index | Thread Index | Old Index