--===============1678787279==
Content-Type: multipart/signed;
boundary="nextPart3089575.3vqFHj3tk0";
protocol="application/pgp-signature";
micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart3089575.3vqFHj3tk0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Lubos Lunak wrote:
>> True. And I think all those "new" that allocate memory that is
>> potentially large should either be in a try/catch block or use
>> new(nothrow) so as to catch bad allocations. One such case is
>> demarshalling a QDataStream.
>
>=A0That still may not actually help that much with memory overcommitting.

That's a different problem.

Memory overcommitting means the memory requested to be allocated was of a=20
reasonable size. And when you run out of memory after overcommitting, the=20
application gets a SIGBUS that's really difficult to understand.

What I am suggesting is getting rid of unreasonable memory allocations.=20
There are many cases of backtraces in bugs.kde.org of applications=20
crashing after std::bad_alloc was thrown from the inside of=20
QString::setLength.

=2D-=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

2. T=F3 cennan his weorc gearu, ymbe se circolwyrde, wear=F0 se c=E6gbord a=
nd se=20
leohtspeccabord, and =FEa m=FDs c=F3mon lator. On =FEone d=E6g, he hine res=
te.

--nextPart3089575.3vqFHj3tk0
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBDluV3M/XwBW70U1gRAiELAKC7wsU8vnhHHGbfbxYwWHbpTR2B8wCdFKbK
2Hr3JDvOk0BT3FFtoGtcYeU=
=Z9zk
-----END PGP SIGNATURE-----

--nextPart3089575.3vqFHj3tk0--

--===============1678787279==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

--===============1678787279==--