From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94433 invoked by alias); 25 Jun 2017 14:28:37 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 92640 invoked by uid 89); 25 Jun 2017 14:28:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=Freddie, freddie, coast, H*r:ip*192.168.1.7 X-HELO: homiemail-a58.g.dreamhost.com Received: from sub5.mail.dreamhost.com (HELO homiemail-a58.g.dreamhost.com) (208.113.200.129) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 25 Jun 2017 14:28:33 +0000 Received: from homiemail-a58.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a58.g.dreamhost.com (Postfix) with ESMTP id 0F4436003516; Sun, 25 Jun 2017 07:28:32 -0700 (PDT) Received: from [192.168.1.7] (pool-72-74-171-167.bstnma.fios.verizon.net [72.74.171.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: drn@nadler.com) by homiemail-a58.g.dreamhost.com (Postfix) with ESMTPSA id BD9516003513; Sun, 25 Jun 2017 07:28:31 -0700 (PDT) From: Dave Nadler Subject: Re: Confusion about possibly unsafe malloc_r? To: Freddie Chopin , newlib@sourceware.org References: <1498371337.1704.1.camel@op.pl> Message-ID: Date: Sun, 25 Jun 2017 14:28:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <1498371337.1704.1.camel@op.pl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00471.txt.bz2 Thanks Freddie. If I understand your answer correctly, printf's call chain's use of _GLOBAL_REENT should be OK because this particular memory is protected by a global lock. I studied the newlib documentation and looked in syscalls, but did not find anything explaining how to implement "retargetable locks" as you mention. I did understand that I must implement env_locks to use set_env/get_env, and that I did not need to implement the corresponding malloc locks. I read a half-dozen articles about embedding/porintg newlib and failed to find this... Could you point me at documentation (or sources) explaining how to implement "retargetable locks"? Thanks for the help! Best Regards, Dave On 6/25/2017 2:15 AM, Freddie Chopin wrote: > On Sat, 2017-06-24 at 18:42 -0400, Dave Nadler wrote: >> Is this OK? I'm paranoid about thread safety! > Then it's worth mentioning that newlib and FreeRTOS will _NEVER_ be > fully thread safe unless you are using a toolchain with retargetable > locks and your project has support code for these locks. > > printf()-style families partially use global reent structure, this is > expected. Trace the calls of the mentioned functions in newlib source > and you'll see that sometimes _GLOBAL_REENT is used, sometimes thread's > reent. > > Regards, > FCh -- Dave Nadler, USA East Coast voice (978) 263-0097,drn@nadler.com, Skype Dave.Nadler1