From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 599BA4765E0 for ; Thu, 24 Dec 2020 20:50:40 +0300 (MSK) Date: Thu, 24 Dec 2020 20:50:34 +0300 From: Igor Munkin Message-ID: <20201224175034.GB5396@tarantool.org> References: <20201207172444.GE5396@tarantool.org> <51ad8f7a-c804-7e06-ceb9-0c8adcc56d16@tarantool.org> <20201220133109.GN5396@tarantool.org> <1cc806a8-62d2-947b-eb74-efd80dafca49@tarantool.org> <20201224132254.GA5396@tarantool.org> <2ab21816-244d-7fd7-48cf-4e7076fbb64f@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2ab21816-244d-7fd7-48cf-4e7076fbb64f@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH 1/4] test: add infrastructure for fuzzing testing and fuzzers List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sergey Bronnikov Cc: tarantool-patches@dev.tarantool.org Sergey, On 24.12.20, Sergey Bronnikov wrote: > Igor, > > >>>>> 2. Do you need to specify
flag once more, when ASAN is > >>>>> enabled? If not the hunk above looks excess, doesn't it? > >>>> Agree, it was a bad idea to manage UBSan and ASAN flags in yet another > >>>> place. > > I guess this should be fixed in scope of the first patch, but I see you > > squashed it to the last one. Why? > > It seems because I was triggered by OSS_FUZZ in hunk and squashed it to > a commit > > that introduce an OSS_FUZZ support. Fixed it and also moved > add_compile_options() to the first commit too > > (otherwise project source code is not instrumented with > -fsanitize=fuzzer-no-link). OK, but I believe we agreed the
options should be removed to avoid managing ASAN flags here, didn't we? > -- Best regards, IM