[gnuastro-devel] [task #14572] Protect gal_data_t's array and block pointers

[Mohammad Akhlaghi]

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/