Date: Tue, 19 May 2020 12:37:23 +0200
From: Wolf <wolf@wolfsden.cz>
To: =?utf-8?B?U8O2cmVu?= Tempel <soeren@soeren-tempel.net>
Cc: ~alpine/devel@lists.alpinelinux.org
Subject: Re: Disable assert statements by default?
Message-ID: <20200519103723.bilvygyghcwaza42@wolfsden.cz>
References: <1ZU8S8ERRPKR9.35CUIBSS8QET7@8pit.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="aqfkjxp224smvdsg"
Content-Disposition: inline
In-Reply-To: <1ZU8S8ERRPKR9.35CUIBSS8QET7@8pit.net>


--aqfkjxp224smvdsg
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hellom

On 2020-05-18 15:56:45 +0200, S=F6ren Tempel wrote:
> [..]
>
> The benefits of disabling asserts by default would be:
>=20
> 	* Users would not run into program crashes triggered by
> 	  development assert statements.
> 	* Would probably cause a minor size reduction.
>=20
> The major drawback imho is that (at least in my experience) programmers
> assume that these assert statements are always true, but never formally
> proof that they are. If there exists a path which causes an assert to be
> false this is a bug which should be fixed. If assert(3) doesn't generate
> any code (i.e. NDEBUG is defined) this causes bugs to go unnoticed.
> Depending on the specific assert statement, this may also lead to
> undefined behaviour (e.g. integer overflows or memory corruptions).
> Undefined behaviour should obviously be avoided and falling asserts are
> much easier to debug than undefined behaviour.

I personally prefer the software to abort on assert then to have memory
corruptions and/or other silent (and possibly hard to notice until it's
too late) issue.

If assert would be triggered, I think it is correct behaviour for
program to abort. That means the issue can be reproduced and reported
upstream. And hopefully fixed.



W.

--=20
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

--aqfkjxp224smvdsg
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE7BIrb0FxyZaks1p7hTP5S2N55TgFAl7DtuMACgkQhTP5S2N5
5TjK2BAAvAn1eTQKMw2sJ1V0xP68IYNgqXF5CUk6n3A7k7KrO/FCrLcMCxksfDlo
JShOKcJTn/wupN+xPhAyzyjs27FZgQ+hUYHuF9t1bzvRH7dKAtgwNCX0Ub+MOvsq
wmmDkjsHN0Sw78dXmbtrpGZ0Pd5iN1vFSEmdOti9dFUoF0M/RkzMrVE0JKaZ8uCh
yeabpd84FIlNd+7Z6ZTjJVzYvDwipHCYWORbdx8ciahcqqOxRFuT7iwlIraYh8Ho
ER3tutvJ7sdkCnVAicuWnUvtmbJrrR2ZpxhCwd4eHB1bwQh541Ll0S8AueIgwh8P
S8P/YRfx32dkuNTmF77i85rYP6vKEYzPVbQ6g1QQIWXdwctFxH1umTFSylPzkMs7
LkHDfGvWVQFvx2EJlknPaBUe6XYDvVGSu1Qe7bYoicr53cm3fd7BVU7RrBxc8uhK
zfxXliyM1RJI0bhCIvGw5yYcb+eMAWD+JVE2OCUGuWq1IztvoUadvG1IgdWqhjWB
8Oh/yU8wxhGBMom0UcU9X0c5yU5ZjXux57QGL+nXjV6y6zDJhTlh+QjkB4lZhIMq
/tLSK6VxU/8H7XPinCTQdKiLTH806k7nh1EoGan1dgDpFBv8O1v9+6+HoFlbae7G
ZW57ET7N3ZTtwy6WUAW1kz45XeC13c2oZilOx01zZ0ppwvdeeT4=
=EyBM
-----END PGP SIGNATURE-----

--aqfkjxp224smvdsg--