[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gnuastro-devel] [task #14572] Protect gal_data_t's array and block poin
From: |
Mohammad Akhlaghi |
Subject: |
[gnuastro-devel] [task #14572] Protect gal_data_t's array and block pointers |
Date: |
Sun, 25 Jun 2017 14:13:51 -0400 (EDT) |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 |
URL:
<http://savannah.gnu.org/task/?14572>
Summary: Protect gal_data_t's array and block pointers
Project: GNU Astronomy Utilities
Submitted by: makhlaghi
Submitted on: Sun 25 Jun 2017 08:13:50 PM CEST
Should Start On: Sun 25 Jun 2017 12:00:00 AM CEST
Should be Finished on: Sun 25 Jun 2017 12:00:00 AM CEST
Category: Libraries
Priority: 5 - Normal
Item Group: Enhancement
Status: Postponed
Privacy: Public
Percent Complete: 0%
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Effort: 0.00
_______________________________________________________
Details:
Gnuastro's generic data container (`gal_data_t') has two pointers that give
information about the region of memory it is related to: `tile' and `block'
(see the manual
<https://www.gnu.org/software/gnuastro/manual/html_node/Generic-data-container.html>).
Currently there is no proper protection and not using these two pointer
properly can cause some really annoying bugs for a programmer using these
low-level features. So it would be very useful to not allow a library user to
manually change these values and define certain functions to the manipulation
of these properties.
In a discussion with Antonio Diaz Diaz, he suggested the following general
suggestion, which I think would be very helpful for the library and its
users.
"I think the standard way of "protecting" a data element in C is defining an
opaque data type and accessing it only through handling functions. Glibc has a
number of such opaque data types (for example the iconv interface
<https://www.gnu.org/software/libc/manual/html_node/Generic-Conversion-Interface.html>).
Lzlib also uses opaque data types (struct LZ_Encoder, struct LZ_Decoder).
But I see no way to prevent the user from freeing the allocated space and
forgetting to call the handling function that sets tile->block to NULL.
Designing a safe and easy to use API is not easy."
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/task/?14572>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [gnuastro-devel] [task #14572] Protect gal_data_t's array and block pointers,
Mohammad Akhlaghi <=