[Top][All Lists]

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

Re: [Bug-apl] Miscellaneous minor fixes

From: Dr . Jürgen Sauermann
Subject: Re: [Bug-apl] Miscellaneous minor fixes
Date: Thu, 4 Jul 2019 15:42:43 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

Hi Alexey,

thanks, I will fix things as suggested.

Regarding signed vs. unsigned, the question is not so much if the chosen type can
hold the value but the number of comparisons needed to compute if a value fits into
a range (where the vast majority of cases the range starts at 0).

A signed X falls into range [0, N] iff:   X ≥ 0 and X < N
An unsigned X
falls into range [0, N] iff:   X < N

For that reason I tend to prefer unsigned over signed. Unfortunately I did not do that consistently.
My class Simple_string (which has now died for good) was using signed instead of unsigned for
the string length. Although unsigned is more efficient in comparisons, unsigned arithmetic is more
dangerous in case of overflows (which was my primary reason for choosing it). This fired back
badly (with milllions of warnings) when I replaced Simple_string<X> with std::string<X> which
uses unsigned for the length.

Best Regards,

On 7/4/19 3:13 PM, Alexey Dokuchaev wrote:
Building APL with GCC 7/8 required some minor patching: src/Error.hh,
in set_error_line_X() methods, there are calls to strncpy(3), so it
needs #include <cstring> or #include <string.h>.

Also, had to change types of total_memory from unsigned to signed,
those values are compared to values of type rlim_t which is signed.
Such comparison causes error.  Since there types are 64-bit, it does
not make sense to make them unsigned, they are huge enough to hold any
reasonable values, be it positive or negative.

On FreeBSD, I've also needed to explicitly #include <sys/socket.h>
which on GNU/Linux is included implicitly via other headers.  And two
calls to ::bind() were missing global namespace specifier which broke
the builds with compilers that default to newish C++ standards.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]