bug-apl
[Top][All Lists]
Advanced

[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 20:08:48 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

Hi Alexey,

I applied most of your patches, thanks for submitting them.

I have left the preferences file as is because changing it could come as a surprise
to users that are happily using the current default.

I also changed the rlim_t comparison warnings in a different way. Please complain
if that doesn't work.

SVN 1179.

BR,
Jürgen


On 7/4/19 5:52 PM, Alexey Dokuchaev wrote:
On 7/4/19, Dr. Jürgen Sauermann <mail@jürgen-sauermann.de> wrote:
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
Understood.  It should not be too hard to fix, just make sure that
your desired types do not conflict with system types like rlim_t, then
either use a compatible type or employ a typecast as a last resort
(typecasts are evil and should be avoided).

This fired back badly (with milllions of warnings) when I replaced
Simple_string<X> with std::string<X> which uses unsigned for the length.
Been these, done that. :-)  Usually, the safest approach when handling
sizes is to use size_t type (which is unsigned, just as you prefer)
and only reluctantly fallback to ssize_t if you need/must to handle
negative sizes for some reason in the same variable (e.g. for error
handling).  Reluctantly because it is generally a bad idea to convey
errors by abusing the data type itself.  Unfortunately, in many
traditional languages there is no support for algebraic data types to
handle these situations in a correct, type-safe way.

./danfe



reply via email to

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