From: Serdar Koylu (serdarkoylu@fisek.com.tr)
Date: Mon 02 Jun 2003 - 12:44:14 EEST
02 Jun 2003 13:28 EEST tarihinde yazmışsınız:
>
>
> GLibc ile ilgili bu dokumani okumak genel olarak faydali olabilir
>
> http://www.gnu.org/manual/glibc-2.2.5/html_mono/libc.html
>
> malloc(), realloc() gibi fonksiyonlarin donus degerleri icin soyle bir=
> tavsiye var dokumanda:
>
> If no more space is available, malloc returns a null pointer. You should=
> check the value of every call to malloc. It is useful to write a=
> subroutine that calls malloc and reports an error if the value is a null=
> pointer, returning only if the value is nonzero. This function is=
> conventionally called xmalloc. Here it is:
>
> void *
> xmalloc (size_t size)
> {
> register void *value =3D malloc (size);
> if (value =3D=3D 0)
> fatal ("virtual memory exhausted");
> return value;
> }
>
> Boyle birseyi kullanmak daha okunabilir programlar saglar. Cunku her hafiza=
> ayrilmasi operasyonunu if'lerle kontrol etmemize gerek kalmaz. Zaten=
> hafiza ayrilamiyorsa problem oldukca buyuktur ve yapacak fazla bisey=
> yoktur. Biz cakilmasak bile baska bir yer nasil olsa cakilacaktir. Oyle=
> bir durumda hafizanin bittigini belirtip cikip gitmek daha iyi. (Hafizasi=
> az kucuk cihazlar icin farkli stratejiler izlenebilir)
>
> Savas
>
>
> > -----Original Message-----
> > From: Serdar Koylu [mailto:serdarkoylu@fisek.com.tr]
> > Sent: Saturday, May 31, 2003 11:23 PM
> > To: linux-programlama@liste.linux.org.tr
> > Subject: [linux-programlama] Re: C'de dosya okumada sorunlar
> >=20
>
> > Bu dongunun bir sekilde 8 kez calismis olmasi soyledigim gibi=20
> > bir tesaduf olmus. Burada sadece biraz acemilik kokuyor.=20
> > Hepimiz acemiydik. Yani, bunu bir tur kotuleme, kinama gibi=20
> > algilamayin. Oncelikle bir pointere dinamik olarak bellek=20
> > atamissaniz bunu hic bir zaman degismeyecek sekilde=20
> > saklamaniz gerekir. Hatta realloc yaparken bile. Mesela:
> >=20
> > ptr =3D malloc(1024);
> >=20
> > .....
> > .....
> >=20
> > ptr =3D realloc(ptr, 2048);
> >=20
> > Bunu yapmak bile tipik bir acemiliktir. Soyleki, ya 2048 bayt=20
> > bellek ayiramazsaniz ? Orijinal bellegin adresini nasil geri=20
> > kazanacaksiniz ? Gerci Linux kolay kolay burada geriye NULL=20
> > dondurmez. OOM killer, elinde baltasi cikar, bulabildigi ne=20
> > kadar program varsa bir guzel budar. Size bellek saglamaya=20
> > calisir. Ama bir programci asla OOM killer'e guvenmemek durumundadir.
> >=20
>
> ---------------------------------------------------------------------------=
> --------------------------------
> Bu mesaj ve ekleri mesajda gonderildigi belirtilen kisi/kisilere ozeldir ve=
> gizlidir.Bu mesajin muhatabi
> olmamaniza ragmen tarafiniza ulasmis olmasi halinde mesaj iceriginin=
> gizliligi ve bu gizlilik y=FCk=FCml=FCl=FCg=FCne
> uyulmasi zorunlulugu tarafiniz icin de soz konusudur.Mesaj ve eklerinde yer=
> alan bilgilerin dogrulugu ve
> g=FCncelligi konusunda gonderenin ya da sirketimizin herhangi bir=
> sorumlulugu bulunmamaktadir.Sirketimiz=20
> mesajin ve bilgilerinin size degisiklige ugrayarak veya gec ulasmasindan, b=
> =FCt=FCnl=FCg=FCn=FCn ve gizliliginin=20
> korunamamasindan, vir=FCs icermesinden ve bilgisayar sisteminize=
> verebilecegi herhangi bir zarardan=20
> sorumlu tutulamaz.
>
> This message and attachments are confidential and intended solely for the=
> individual(s) stated in this
> message.If you received this message although you are not the addressee you=
> are responsible to keep=20
> confidential the message.The sender has no responsibility for the accuracy=
> or correctness of the=20
> information in the message and its attachments.Our company shall have no=
> liability for any changes
> or late receiving,loss of integrity and confidentiality,viruses and any=
> damages caused in=20
> anyway to your computer system.
>