Why can't a single condvar be used with multiple mutexes?

[Danny Niu via austin-group-l at The Open Group]

Hi, all. 

I realize this is busy time for the group to work
on the next version of the standard, and I hope 
I'm not being too disruptive.

In pthread_cond_wait and pthread_cond_timedwait, 
it is unspecified when a single condition variable
is used with more than one mutex. I suppose such
provision is made to accommodate some existing 
implementation(s), so can someone confirm or
refute this? 

Re: Question regarding gettext behavior on iconv failure

[Bruno Haible via austin-group-l at The Open Group]

Carlos O'Donell wrote:
> > 1 Empfaenger Chinese (??,???,??)  ??
> >   * For the second line of output, in the first three cases, iconv()
> > did transliteration, and the result was always an ASCII string.
> > (The quality of glibc's transliteration of Hanzi characters to
> > question marks can be debated, though.)
> 
> Completely off-topic, but is there a "high quality" transliteration of
> Hanzi characters?
> Would you have expected a phenome to be spelled out in ASCII?
> I am not aware of any way to keep the meaning of the Hanzi characters in
> ASCII, therefore you see the locales "default_missing" character U+003F '?'.

Let's discuss this on libc-alpha. [1]

Bruno

[1] https://sourceware.org/pipermail/libc-alpha/

Re: Question regarding gettext behavior on iconv failure

[Bruno Haible via austin-group-l at The Open Group]

Eric Ackermann wrote:
> please find attached another test case (a shortened version of the
> example in the gettext proposal that Eric Blake linked). It uses the
> same mail.po and mail-utf8.po files that you provided earlier.
> When I compile and run it on Ubuntu 20.04 (Ubuntu GLIBC
> 2.31-0ubuntu9.2), for both .po files it prints "Empf?nger" in ASCII
> (converting the a-Umlaut into the question mark). This is probably
> related to the transliteration mechanism you described.

This demo.c example is not a good test case, because it does not
follow the advice to set at least the LC_MESSAGES and LC_CTYPE categories
of the locale. See

and  line 86.

What happens then is that the LC_CTYPE category of the locale is, by default,
set to "C", which implies "ASCII" encoding and no particular language or
territory. glibc's transliteration uses the language to determine the
transliteration to use. For example, it transliterates "å" to "aa" in a
Danish locale, but to "a" in an English locale. In the absence of a known
language, it falls back to "?" (like for the Chinese characters in my
previous mail).

> I conclude that the different sequence in which the
> gettext-functions are called causes this behavior which I would consider
> a bug.

No, there is no bug. The doc states that the LC_MESSAGES and LC_CTYPE
categories should be set, for gettext() to operate reasonably.

Bruno

[Issue 8 drafts 0001469]: Inconsistent return type for tfind and tsearch

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://austingroupbugs.net/view.php?id=1469 
== 
Reported By:dennisw
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1469
Category:   Base Definitions and Headers
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Dennis Wölfing 
Organization:
User Reference:  
Section: 
Page Number:316 
Line Number:11052-11055 
Final Accepted Text: 
== 
Date Submitted: 2021-05-04 16:03 UTC
Last Modified:  2021-05-04 16:03 UTC
== 
Summary:Inconsistent return type for tfind and tsearch
Description: 
https://austingroupbugs.net/view.php?id=1011 added the posix_tnode type and
changed the return types of tfind
and tsearch to posix_tnode*. However in the current draft the return type
is only changed in XSH but not in XBD .
Desired Action: 
On page 316 line 11052-11055 changevoid *tfind(const void
*, posix_tnode *const *,
int(*)(const void *, const void *));
void *tsearch(const void *, posix_tnode **,
int(*)(const void *, const void
*));toposix_tnode *tfind(const void *,
posix_tnode *const *,
int(*)(const void *, const void *));
posix_tnode *tsearch(const void *, posix_tnode **,
int(*)(const void *, const void *));
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2021-05-04 16:03 denniswNew Issue
2021-05-04 16:03 denniswName  => Dennis Wölfing 
2021-05-04 16:03 denniswSection   =>   
2021-05-04 16:03 denniswPage Number   => 316 
2021-05-04 16:03 denniswLine Number   => 11052-11055 
==

Re: Question regarding gettext behavior on iconv failure

[Eric Ackermann via austin-group-l at The Open Group]

> No. Please provide a reproducible test case, that produces wrong
> results on an interesting platform. NetBSD 3.0 or IRIX 6.5, for
 > example, don't count.

Hello Mr Haible,

please find attached another test case (a shortened version of the
example in the gettext proposal that Eric Blake linked). It uses the
same mail.po and mail-utf8.po files that you provided earlier.
When I compile and run it on Ubuntu 20.04 (Ubuntu GLIBC
2.31-0ubuntu9.2), for both .po files it prints "Empf?nger" in ASCII
(converting the a-Umlaut into the question mark). This is probably
related to the transliteration mechanism you described.
I originally thought that the "?" was printed by my terminal and that
the output was printed without conversion, but when I investigated the
individual bytes with hexdump again, I noticed that actually an ASCII
question mark is printed.
However, the test case you sent earlier works on the same system as
documented, transliterating to "Empfaenger" correctly.
Because of this, I conclude that the different sequence in which the
gettext-functions are called causes this behavior which I would consider
a bug.

Kind regards,

Eric Ackermann,
student at HPI, University of Potsdam
/* Preparations:
- Install locale named 'de_DE.UTF-8' (using localedef).
- Find mail.po as provided by Bruno Haible
- $ mkdir -p de/LC_MESSAGES
  $ msgfmt -c -o de/LC_MESSAGES/mail.mo mail.po
  or
  $ msgfmt -c -o de/LC_MESSAGES/mail.mo mail-utf8.po
- $ gcc -Wall demo.c
- $ LANG="" LANGUAGE="" ./demo
*/
#include 
#include 
#include 
#include 
#include 
int main(void){
unsigned long n_recipients;

setlocale(LC_MESSAGES, "de_DE");
bindtextdomain("mail", ".");
textdomain("mail");
bind_textdomain_codeset("mail", "ASCII");


n_recipients = 1;

printf("%s\n", ngettext("recipient", "recipients", n_recipients));

// Outputs "1 Empf?nger" on up-to-date Ubuntu 20.04.
}

Austin Group teleconference +1 888 974 9888 PIN 618 156 403

[Single UNIX Specification via austin-group-l at The Open Group]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1//
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:20120311T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:20121104T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:6091381c83...@opengroup.org
DTSTAMP:20210504T120340Z
ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org
CREATED:20210504T00Z
DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel
 econference +1 888 974 9888 PIN 618 156 403\nDate/Time: 10-May-2021 at 11:
 00 America/New_York\nDuration: 1.50 hours\nURL: https://collaboration.open
 group.org/platform/single_unix_specification/events.php\n\n* All calls are
  anchored on US time **\n\nTopic: Austin Group teleconference\n---
 \nAudio conference information
 \n---\n\nYou are invit
 ed to a Zoom meeting.\n\nMeeting ID: 618 156 403\n\nJoin from PC\, Mac\, i
 OS or Android: https://logitech.zoom.us/j/618156403\n \nor join by phone:
 \nUS: 888 974 9888\nUK: 800 031 5717\nDE: 800 724 3138\nFR: 805 082 588\n
 \nOther international numbers available here:\nhttps://zoom.us/u/adlvrb8IL
 j\n \nMeeting ID: 618 156 403\n\nor join from a H.323/SIP Device:\n   
  Dial: 162.255.37.11 (US West) or 162.255.36.11 (US East)\nMeeting ID:
  618 156 403\n\nShare from a PC or MAC: https://zoom.us/share/618156403\n
 \nOr iPhone one-tap (US Toll):  +16699006833\,618156403# or +16465588656\,
 618156403#\n\nPassword for zoom call  ends with x\n\nAll Austin Group part
 icipants are most welcome to join the call.\nThe call will last for 90 min
 utes.\n\n\nAn etherpad is usually up for a meeting\, with a URL using the 
 date format as below:\n\nhttps://posix.rhansen.org/p/202x-mm-dd\n\nLOGIN R
 EQUIRED to write to the ETHERPAD (Use your gitlab.opengroup.org login.)\n
 \n\n\nBug reports are available at:\nhttps://www.austingroupbugs.net\n
DTSTART;TZID=America/New_York:20210510T11
DURATION:PT1H30M0S
LAST-MODIFIED:20210504T080340Z
ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Austin Group teleconference +1 888 974 9888 PIN 618 156 403
TRANSP:OPAQUE
URL:https://collaboration.opengroup.org/platform/single_unix_specification/
 events.php
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-VISIBILITY:40
X-JOINBEFORE:5
X-CATEGORY:Teleconference
X-PLATO-SITE:Single UNIX Specification
X-PLATO-SITEID:136
END:VEVENT
END:VCALENDAR


meeting.ics
Description: application/ics

Minutes of the 3rd May 2021 Teleconference

[Andrew Josey via austin-group-l at The Open Group]

All
Enclosed are the minutes from yesterday
regards
Andrew
--

Minutes of the 3rd May 2021 Teleconference Austin-1125 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 4th May 2021

Attendees:

Nick Stoughton, USENIX, ISO/IEC JTC 1 / SC 22 OR
Don Cragun, IEEE PASC OR
Joerg Schilling
Richard Hansen
Eric Ackermann, HPI, University of Potsdam 
Mark Ziegast, SHware Systems Dev.
Eric Blake, Red Hat, The Open Group OR

Apologies:
Andrew Josey, The Open Group
Geoff Clare, The Open Group


* General news 

This was a call dedicated to gettext discussions.
General bugs are now discussed on Thursdays.


* Outstanding actions

(Please note that this section has been flushed to shorten the minutes -
to locate the previous set of outstanding actions, look to the minutes
from 13th June 2019 and earlier)

Bug 1254: "asynchronous list" description uses "command" instead of "AND-OR 
list" OPEN
https://austingroupbugs.net/view.php?id=1254
Action: Joerg to investigate how his shell behaves.

Bug 700 - Nick to raise this issue with the C committee
Bug 713 - Nick to raise with the C committee.
Bug 739 - Nick to raise with the C committee.


* Current Business

Bug 1122: POSIX should include gettext() and friends

We continued discussions on the gettext draft.

The gettext draft in the etherpad is at

https://posix.rhansen.org/p/gettext_draft
https://posix.rhansen.org/p/gettext_split


The next call will be a general bugs call on Thursday.

Next Steps 
--

The next calls are on:

May 6th 2021 (Thursday)   General Bugs
This call will be for 90 minutes.

May 10th 2021 (Monday)  Gettext
This call will be for 90 minutes.

Calls are anchored on US time. (8am Pacific) 


Please check the calendar invites for dial in details.

Bugs are at:
https://austingroupbugs.net

Apologies in advance:
Eric Ackermann, Thu 2021-05-06

An etherpad is usually up for the meeting, with a URL using the date format as 
below:

https://posix.rhansen.org/p/20xx-mm-dd

(For write access this uses The Open Group single sign on,
for those individuals with gitlab.opengroup.org accounts.
Please contact Andrew if you need to be setup)


Andrew JoseyThe Open Group
Austin Group Chair  
Email: a.jo...@opengroup.org 
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England

To learn how we maintain your privacy, please review The Open Group Privacy 
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group 
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481