help-gsl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gsl] test release for GSL 2.4


From: maxgacode
Subject: Re: [Help-gsl] test release for GSL 2.4
Date: Tue, 20 Jun 2017 23:02:11 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1

Il 15/06/2017 10:27, Patrick Alken ha scritto:
Hi all,

   There is now a new test release here:

ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz
ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz.sig


I'm trying to compile GSL 2.4 but I'm observing a lot of serious issues.

Platform Windows 7 64 bit latest SP.
MinGW64 with GCC 6.1.0

Using the same platform and compiler I successfully compiled GSL 2.3 without any issues using both optimization and debugging options.

I'd like to start with the most important issue. I'm observing several sistematic "segmentatio fault" in both vector and matrix tests.

At the moment I'm trying to understand better the issue but I have a doubt.

In the past a "bug" was reported (bug #49988) related to a "follow the style of malloc and free" documentation imprecision.

To fix that "imprecision" GSL added the support for  "zero-length objects"

Ok now from facts to my guess....

Reading the source code I understood that in the end you are doing something like

malloc(0)

a thing the "should never be done" (as I've been told during my C course at University).

Ok, having passed the time that may be done today......but my guess is still that malloc(0) shuold never be done.

Looking at ISO/IEC 9899:1999


7.20.3 Memory management functions

...... If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object.

and in ISO/IEC 9899:201x

7.22.3 Memory management functions

If the space cannot be allocated, a null pointer is returned. If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object.

You can call free but not deferencing the pointer.

So adding "zero-length objects" had (in my opinion) made GSL no longer portable, implementation defined or even worse unspecified in some implementation.

In fact in both standard you can also find the following reason for an unspecified behavior


Section J

- The amount of storage allocated by a successful call to the calloc, malloc, or realloc function when 0 bytes was requested (7.20.3).


May be in some (or most) platform works but it seems quite strange to me to consider an "unspecified behavior" acceptable just to correct a minor imprecision of the documentation. IMHO is better to change the documentation....

Is really useful in the "real life" to allocate a zero lenght vector? I prefer to get an assertion (calling an error handler) of problem becasue usually (IMHO) a malloc(0) is due to a buggy code. A malloc(0) may returns a non NULL pointer to a block of zero byte memmory....at that point you can deferencing it......

My current guess is that I'm observing a segmentation fault as a result of a malloc(0) but I may be wrong and I'm still investigating the issue, but in any case I'm wondering if a "revert" may be better for GSL.


I'd like to know your opinion.

As a further reference look at the book

The CERT C Secure Coding Standard
By Robert C. Seacord


Regards

Max









reply via email to

[Prev in Thread] Current Thread [Next in Thread]