newlib cvs opendir family leaks?

[Joel Sherrill]

Eric sent this without cc'ing the list.  Looks like the
stb.st_size == 0 check needs to be there.

Eric Norum wrote:
> It is certainly not safe to assume that malloc(0) returns NULL.
> In C99, malloc(0) is legal. From n869.txt : %% 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.

Joel Sherrill wrote:
> Hi,
>
> I found the problem.  scandir() does not call closedir()
> on any error path.  I also question whether it is
> safe to assume that malloc(0) returns NULL
>
> Attached is the RTEMS version which is based
> upon the one from newlib 1.8.0.  Look at where
> the RTEMS version has "goto cleanup_and_bail;"
> It also looks like the current newlib version may
> be leaking memory based upon the RTEMS version.
>
> I  think it would be more obvious to check
> stb.st_size == 0 and return explicitly rather
> than doing math and then calling malloc(0).
>
> Now the question is how do you guys
> want to fix it.  Is the "goto cleanup and bail"
> approach ok since there are so many exit
> paths and so much to potentially clean?
>
> --joel
>
>
> Joel Sherrill wrote:
>   
>> Hi,
>>
>> Just a heads up in case someone can identify
>> this before I do.  The RTEMS readdir() test
>> fails after switching to newlib's readdir() family.
>> I have tracked this down to the newlib implementation
>> leaking file descriptors.
>>
>> With RTEMS, we configure a hard limit on the number
>> of concurrent open file descriptors.
>>
>> I tried to desk check this out but didn't spot it.
>> I am working on it but hoped someone might see
>> something wrong in the code.
>>
>> Thanks.
>>
>>   
>>     
>
>
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985