Posible memory leak en bitarray.c about so-commons-library

[mgarciaisaia]

Como regla general, en un TAD no liberás memoria que no reservaste vos, porque no sabés de dónde vino esa memoria (es decir, no tenés garantías de que sea liberable, siquiera). Podés poner como restricción de tu API que vas sa terminar liberando esa memoria (y entonces pasa a ser problema del usuario asegurarse de que la memoria que te pase sea liberable), pero en general nadie gana nada con eso, y limitás casos de uso (no te pueden pasar memoria no-liberable por free). Digamos, si alguien va a llamar a tu xxxx_destroy de todos modos, puede tomarse la molestia de hacer un free justo después del destroy si hiciera falta.

Pero haciendo esto que hace este TAD ganás en eso: podés pasarle un cacho de memoria que no sea manejada por malloc/free. Seguramente en este TAD lo implementamos así para usar en algún TP cuyo bitarray estaba persistido en un archivo (en el filesystem), y entonces podés mmapear ese archivo y usar el TAD de bitarray directamente contra ese archivo mappeado en memoria, y entonces trabajás de manera medio transparente con ese bitarray que está persistido en el disco.

Y si querés laburar con un bitarray en memoria, buen, tampoco es tan complejo: hacés un malloc() antes de llamar al create, y le pasás ese array. Y después lo liberás cuando llamás a destroy.

Y el TAD soporta dos casos de uso distintos por el precio de uno. Una ganga.