[Bug 1620] Issues with rtems_libio_share_private_env at cpukit/libcsupport/src/privateenv.c

[bugzilla-daemon at rtems.org]

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

Bharath Suri <bharath.s.jois at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #951 is|0                           |1
           obsolete|                            |

--- Comment #10 from Bharath Suri <bharath.s.jois at gmail.com> 2010-07-29 16:51:41 CDT ---
Created an attachment (id=953)
 --> (https://www.rtems.org/bugzilla/attachment.cgi?id=953)
Patch @ cpukit/libcsupport/src

Same as comment #8

Patch to cpukit/libcsupport/src
Previous patch did not have the change in rtems_libio_set_private_env, hence
the new patch.

This is a proposed patch. 

Changes:

rtems_libio_share_private_env now does the following:

- Get the current task's ID
- If the attempt is to share the environment with current task, return OK
- Else continue
- Try to get the rtems_current_user_env variable of the other task into the
shared_user_env
- If error, return with the status code
- else, we have a good environment, which we need to share
- Now, check the rtems_current_user_env to see if it has its own environment
- If it does, free that environment
- now, set the rtems_current_user_env = shared_user_env
- return OK

Change in rtems_libio_set_private_env:

- The check
  if (rtems_current_user_env==&rtems_global_user_env )
is changed to 
  if (rtems_current_user_env==&rtems_global_user_env || 
      rtems_current_user_env->task_id != task_id )

The current task does not have its own environment in two cases
- when it was not set previously
- when it shared another task's environment

I would like to know if the second check is completely safe.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.