From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20759 invoked by alias); 7 Oct 2011 16:30:17 -0000 Received: (qmail 20748 invoked by uid 22791); 7 Oct 2011 16:30:15 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 07 Oct 2011 16:30:01 +0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sources.redhat.com Subject: [Bug libc/13271] getaddrinfo is not thread safe Date: Fri, 07 Oct 2011 16:30:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2011-10/txt/msg00028.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=13271 --- Comment #4 from Rich Felker 2011-10-07 16:29:26 UTC --- 2.9.1 states very explicitly, "any function dependent on any environment variable is not thread-safe if another thread is modifying the environment". The only potential wiggle-room to claim that glibc is non-conformant is that getaddrinfo is not documented (by the standard or by the implementation) as depending on the environment. With that said, I agree that Ulrich Drepper is wrong to claim that modifying the environment in a multi-threaded program is not allowed. It can be done safely in many situations, such as when all but one thread is purely computational or only invoking only async-signal-safe functions. It should also be perfectly safe if you modify extern char **environ; (or the array it points to) directly in only atomic ways and don't clobber any environment memory that other threads could still be referencing. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.