Re: perspektiva řady Xmega od Atmelu

[Marek Sembol]

ale jo, ono to bylo pro pomoc s odhalovanim chyb. A mne osobne to i
mnohokrat pomohlo. Ale nic se neudela samo.
Ono kdyz si cmarate "kousicek za alokovany blok" (nejcastejsi chyba) nemate
jak odhalit v momente zapisu. Ta pamet tam je. Jen uz patri "nekomu jinemu"
(jiny alokovany blok nebo spis jeho hlavicka). Takze si porusite strukturu
heapu a k padu dojde az "nekdy v budoucnu". Kdyz tam mate tu "rezervu", tak
nejen, ze neporusite heap (prepisujete nevyznamna data), ale jste to
schopen i detekovat (funkce na kontrolu to odhali). Ale musi k volani te
"kontrolni funkce" dojit. At uz explicitne, nebo alespon implicitne (napr.
v ramci delete).
Podrobnosti uz nepotrebuji, pokud vas zajimaji, tak napr.
https://msdn.microsoft.com/en-us/library/974tc9t1.aspx
Marek


2015-05-30 17:57 GMT+02:00 Petr Tomasek <tomasek na etf.cuni.cz>:

> On Sat, May 30, 2015 at 11:57:51AM +0200, Marek Sembol wrote:
> > A je fakt, se to (hlavne ten alloc - vic pameti) obcas projevilo tak, ze
> > program "fungoval". Ale to snad neni duvod plut na MSVC kdyz si
> programator
> > pouziva neicializovane promenne nebo cmara mimo pridelenou pamet?
> > Marek
>
> No, nevim, s MSVC jsem nikdy nedelal, ale pokud tomu tak skutecne je,
> pak to maji udelane hodne hloupe, protoze debug mod ma uz ze sveho
> principu pomoci chyby odhalit a ne je schovat...
>
> (Brrr... tohle si primo rika o nejaky buffer-overrun... :-( )
>
> P.T.
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20150530/9ec27d37/attachment.html>