On Wed, 15 Jan 2003, Mihnea-Costin Grigore wrote: > > Salve! > > Are cineva idee daca exista vreo functie in C (cat mai portabila!) > care returneaza spatiul alocat pentru un pointer? Adica, ceva de genul: > > ... > int *p = (int *) malloc (100 * sizeof(int)); > ... > n = get_allocated_size (p); /* => n == 400, daca sizeof(int) == 4 */ > > Impartind n la tipul pointer-ului, se poate afla numarul de elemente > de tipul respectiv care sunt alocate incepand cu p, ceea ce este foarte > util in anumite circumstante. > > Intreband pe ici pe colo si cautand pe google, am reusit sa determin > urmatoare formula sapand prin malloc.c - din pacate este _extrem_ > de neportabila si limitata la cazul glibc-2.x pe Linux: > > size_t n = *(size_t *)((char *)(p) - sizeof(size_t)); > n = ((n & ~(0x1UL | 0x2UL)) - 2 * sizeof(size_t)); > > In libc-ul care vine cu MinGW32 (o versiune de acum cateva luni), > chestia de mai sus nu merge, si trebuie facut asa: > > size_t n = *(size_t *)((char *)(p-2)); > > Ma gandeam ca ar trebui sa existe o functie pentru treaba asta, in > fond free(); este portabila si face exact acest lucru (adica se uita in > tabela de memorie alocata pentru fiecare "chunk" si ia de acolo valoarea). > Daca free(); o face, o poate face orice functie, cu conditia sa aiba acces > la datele interne din malloc.c (sau echivalent). > > Multumesc pentru orice sugestie... >
free() este portabila doar in ideea ca cei care au scris malloc au scris si free. deci cand muti programul pe un alt sistem/OS/libc atunci e foarte probabil sa nu mai fie portabila functia ta. nu au facut una deja pt un motiv foarte simplu: daca chiar ai nevoie de asa ceva de ce nu redefinesti malloc/free proprii si tii evidenta alocarilor (facandu-le ca niste wrappere). Iar daca obiectivul tau e memory debugging in general iti dau un URL care mie mi s-a parut genial (nu URL-ul, ci programul de acolo), si chiar am lucrat cu el la greu: http://developer.kde.org/~sewardj/ un mic extras: Valgrind, an open-source memory debugger for x86-GNU/Linux Valgrind is a GPL'd tool to help you find memory-management problems in your programs. When a program is run under Valgrind's supervision, all reads and writes of memory are checked, and calls to malloc/new/free/delete are intercepted. As a result, Valgrind can detect problems such as: * Use of uninitialised memory * Reading/writing memory after it has been free'd * Reading/writing off the end of malloc'd blocks * Reading/writing inappropriate areas on the stack * Memory leaks -- where pointers to malloc'd blocks are lost forever * Passing of uninitialised and/or unaddressible memory to system calls * Mismatched use of malloc/new/new [] vs free/delete/delete [] * Some misuses of the POSIX pthreads API Valgrind tracks each byte of memory in the original program with nine status bits, one of which tracks addressibility of that byte, while the other eight track the validity of the byte. As a result, it can detect the use of single uninitialised bits, and does not report spurious errors on bitfield operations. Si nu e vrajeala, chiar merge beton si face ce zice el acolo... ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. --- Pentru dezabonare, trimiteti mail la [EMAIL PROTECTED] cu subiectul 'unsubscribe rlug'. REGULI, arhive si alte informatii: http://www.lug.ro/mlist/
