change log for rtems (2010-04-28)

[Chris Johns]

On 4/29/2010 9:47 AM, Joel Sherrill wrote:
> On 04/28/2010 05:20 PM, Chris Johns wrote:
>> On 29/04/2010 1:11 AM, rtems-vc at rtems.org wrote:
>>> + if ( !pathname )
>>> + rtems_set_errno_and_return_minus_one( EFAULT );
>>> +
>> I think this change is hiding a deeper problem we need to fix. I think
>> this change should be reverted so the test that exposes it can test the
>> real solution.
>>
> psxfile01 is and was explicitly calling chdir(NULL). I just
> happened to run on a target that faulted with it.

I like the test. If chdir tests this then we should not need to cover 
open etc etc.

>>> /*
>>> * Get the node where we wish to go.
>>> */
>>> -
>>> result = rtems_filesystem_evaluate_path(
>>> pathname, strlen( pathname ), RTEMS_LIBIO_PERMS_SEARCH,&loc, true );
>>> if ( result != 0 )
>> I changed this call to pass the length of a string which means the test
>> in rtems_filesystem_evaluate_path call for pathname == NULL can never
>> happen because the strlen call would fail first. My change did not deal
>> with this case.
>>
>> A couple of solutions are:
>>
>> 1. Add a rtems_filesystem_stlen call that checks for NULL and update
>> all call sites.
>> 2. Add a rtems_filesystem_evaluate_path_len (or something) and update
>> the location of those places that need the length.
>> 3. Any others ?
>>
>> The change was made to remove the endless need for code in file systems
>> or libc level code from having to copy a string to new memory to make
>> the call. It is common in the code to iterate down a path by taking just
>> a piece at a time. The copy meant heap allocations all for a small
>> section of a string when looking up a path.
>>
> I wasn't intentionally covering this up.

Sorry, I never assumed you would.

> If you want to
> change it to an fs_strlen, feel free. I was just adding
> a missing NULL check.

I will. I have added a PR:

https://www.rtems.org/bugzilla/show_bug.cgi?id=1508

Chris