From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 77EEC21E87986 for ; Wed, 13 Sep 2017 11:49:04 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id v36so6447180ioi.1 for ; Wed, 13 Sep 2017 11:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ajNLJ/2xdk1FFZ3q8F6Hmby8jzduLmXlhpdQa+2Fk70=; b=cZ0ZLe7UB58MrtIXFyI6q1tt3NnGiMgGGU5n/9viZQdmx40gqHHYqoYKZVlERtPJS4 8yJYP2AkFiq4S/P0+A/mxpxO1MFQlpYDNO0yRBxwHDXx6t2aiMHX8cmkTeVsHcuTai2t 8LK7X703u/ndcgDo+gHM57IWdmKEConWafTbs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ajNLJ/2xdk1FFZ3q8F6Hmby8jzduLmXlhpdQa+2Fk70=; b=Xa1efbOLxgEpUv2HU4eFvy9E2nfXsnT1APHYAIp3pSGtAz3eJORTjhqUdl1lMLbdgZ b3XYImF6v1KswtVdSvDTKWOBbPS1o7TJWkVOrVEFWV/2my9KCzFLsGINJKh2zPvTagmb ecJ7GigLHShQLWJXoRtNDvkgx8j1c4geoIUjMvBSNWLl/YS4H0OVLB+5+rmanCwR0oJW 0hlIFFwKg70B1HnviYgB0NDn2WKivP2UMhVebvNGZSjdVc/fi1unY3vBdL5ZWXodAzuF MQ6mDcHh1/+HlP/ARU96OxdjCWUjLDlpeT01BTF+fZfIW/uElWTbY0eFeMuAt2fNSwCc JX7w== X-Gm-Message-State: AHPjjUgpqk+DK9RrwFOOB2GaJc/LrE2ejo4xmFLEC/TpCeb1O2tNIse6 RIYAQBHQMW8yJx69tpEaUEq3wrgA6PqjUxtjYUml6Q== X-Google-Smtp-Source: AOwi7QASjntSug6tccKN4eoQ/8JGdzkzRD/3kM+S9A6R/GPwu9ncUgqqF6Hvxz5Czs/M7fze6qp62a6Px/YU9rlKmmg= X-Received: by 10.107.43.69 with SMTP id r66mr26287204ior.2.1505328721995; Wed, 13 Sep 2017 11:52:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.152.18 with HTTP; Wed, 13 Sep 2017 11:52:01 -0700 (PDT) In-Reply-To: <23e789a8-59df-d67d-fa16-fc70aafb95d7@redhat.com> References: <20170912222612.14451-1-lersek@redhat.com> <20170912222612.14451-3-lersek@redhat.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B94098B@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B9409E7@shsmsx102.ccr.corp.intel.com> <23e789a8-59df-d67d-fa16-fc70aafb95d7@redhat.com> From: Ard Biesheuvel Date: Wed, 13 Sep 2017 11:52:01 -0700 Message-ID: To: Laszlo Ersek Cc: "Zeng, Star" , edk2-devel-01 , "Dong, Eric" , Paulo Alcantara , "Ni, Ruiyu" , "Gao, Liming" Subject: Re: [PATCH 2/2] MdeModulePkg/UdfDxe: suppress incorrect compiler warning in ReadFile() X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 18:49:04 -0000 Content-Type: text/plain; charset="UTF-8" On 13 September 2017 at 11:49, Laszlo Ersek wrote: > On 09/13/17 08:43, Zeng, Star wrote: >> Beyond the Rb (I do not want to block this patch series), I am curious about one question. >> >> There may be more this kind of workarounds to fix the build failure. >> Is it possible to disable the warning (like below example for VS) for specific version of GCC for this kind of false alarm? >> >> >> ProcessorBind.h: >> #if defined(_MSC_EXTENSIONS) >> >> ... >> >> #if _MSC_VER == 1800 || _MSC_VER == 1900 >> >> // >> // Disable these warnings for VS2013. >> // >> >> // >> // This warning is for potentially uninitialized local variable, and it may cause false >> // positive issues in VS2013 and VS2015 build >> // >> #pragma warning ( disable : 4701 ) >> >> // >> // This warning is for potentially uninitialized local pointer variable, and it may cause >> // false positive issues in VS2013 and VS2015 build >> // >> #pragma warning ( disable : 4703 ) >> >> #endif >> >> #endif > > I think starting with gcc-4.6, gcc supports the "diagnostics" pragma, > which can be used to suppress warnings. > > Unfortunately, there's no pragma to suppress *only* the incorrect > warnings :) So if we set the pragma, we could lose even those warnings > that point out real bugs. > That applies to the VS case as well. But I think doing this for older GCCs is fine, most EDK2 developers use a newer version anyway, so we will not lose any coverage by doing so.