Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0000665 [1003.1(2008)/Issue 7] System Interfaces Editorial Omission 2013-02-25 21:53 2013-02-27 17:03
Reporter dalias View Status public  
Assigned To ajosey
Priority normal Resolution Withdrawn  
Status Closed  
Name Rich Felker
Organization musl libc
User Reference
Section pthread_mutex_unlock
Page Number unknown
Line Number unknown
Interp Status ---
Final Accepted Text
Summary 0000665: Errors section for pthread_mutex_unlock is missing an error case mandated in the description
Description The description reads:

"If the mutex type is PTHREAD_MUTEX_RECURSIVE, then the mutex shall maintain the concept of a lock count. When a thread successfully acquires a mutex for the first time, the lock count shall be set to one. Every time a thread relocks this mutex, the lock count shall be incremented by one. Each time the thread unlocks the mutex, the lock count shall be decremented by one. When the lock count reaches zero, the mutex shall become available for other threads to acquire. If a thread attempts to unlock a mutex that it has not locked or a mutex which is unlocked, an error shall be returned."

However, the errors section only mandates one ERROR for pthread_mutex_unlock, and only in the case of error-checking or robust mutexes:

"The pthread_mutex_unlock() function shall fail if:

[EPERM]
The mutex type is PTHREAD_MUTEX_ERRORCHECK or the mutex is a robust mutex, and the current thread does not own the mutex."
Desired Action Change the above quoted text in the errors section to:

"The pthread_mutex_unlock() function shall fail if:

[EPERM]
The mutex type is PTHREAD_MUTEX_RECURSIVE or PTHREAD_MUTEX_ERRORCHECK or the mutex is a robust mutex, and the current thread does not own the mutex."
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0001478)
geoffclare (manager)
2013-02-26 09:59

 This is already fixed in TC1. See http://austingroupbugs.net/view.php?id=121#c159 [^]

Rich, would you like to withdraw this bug? Otherwise it will be resolved as a duplicate of 0000121.

- Issue History
Date Modified Username Field Change
2013-02-25 21:53 dalias New Issue
2013-02-25 21:53 dalias Status New => Under Review
2013-02-25 21:53 dalias Assigned To => ajosey
2013-02-25 21:53 dalias Name => Rich Felker
2013-02-25 21:53 dalias Organization => musl libc
2013-02-25 21:53 dalias Section => pthread_mutex_unlock
2013-02-25 21:53 dalias Page Number => unknown
2013-02-25 21:53 dalias Line Number => unknown
2013-02-26 09:59 geoffclare Note Added: 0001478
2013-02-26 11:21 dalias Resolution Open => Withdrawn
2013-02-27 17:03 geoffclare Interp Status => ---
2013-02-27 17:03 geoffclare Status Under Review => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker