From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by sourceware.org (Postfix) with ESMTP id 7318D3851C04 for ; Sun, 31 May 2020 15:21:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7318D3851C04 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-53-X2aGsWnUMAy-BOzeyVI7Zw-1; Sun, 31 May 2020 11:21:09 -0400 X-MC-Unique: X2aGsWnUMAy-BOzeyVI7Zw-1 Received: by mail-wr1-f72.google.com with SMTP id o1so3529742wrm.17 for ; Sun, 31 May 2020 08:21:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lWaCeZT9o58x7c1z/ZO1Pe7HodPSuhBdGb0Vi80YfpA=; b=ITK6PQPoMqngBaM7l+oP6XvrwieC+RfSAhGLqeog/6vG67SbwtHQrlXbhItRNbLmwy qdc7eoRFzgxtO4eV8h7awuyn881WEms0xFsStD9fx/yBEtHgtHTChqzLwScSLX8d97GO KX2y6l6Dl+SpP3KnOm+jzGOhwZ8Qpg9TEOAolhEkL3l3MgwDwLQQGmS8gI1IDDVsCwby bnaiy9FWRLugB9J5aAbZJiBgwMNNVwS6QOx/nSt9AjqyqLL8xzse27tqV1ToAgUbVWt7 3iKTlu5isyNF3FkOfPedFQFivlWGQWu1etcpIqVJ9B/GxQxq/5yjUFrGjdXkn6eISypv 3eTg== X-Gm-Message-State: AOAM5316n50nxDJdNmQ6rhhvjIxYXfq21MaxS+k1FnAB3Rn1OcYjRuaJ Er5JJF4w5roHp3a+uyPXtvTc51V8uJeh2JJd1LS7A9EZEcHloqfeVbtDAz9eaPuzBWXim66IP2H MkQn5wpwvTqhwlRtQedwQew== X-Received: by 2002:a05:6000:120b:: with SMTP id e11mr17917369wrx.107.1590938468071; Sun, 31 May 2020 08:21:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwMxGm2Gwt+S6YmgoAtkWmvg+d6E5XmCdB8KYOZ0UhF2mOIhwS6s0NUg24n6CclQg9gaILCLA== X-Received: by 2002:a05:6000:120b:: with SMTP id e11mr17917357wrx.107.1590938467871; Sun, 31 May 2020 08:21:07 -0700 (PDT) Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id 125sm7955796wmc.23.2020.05.31.08.21.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 31 May 2020 08:21:07 -0700 (PDT) Subject: Re: [PATCH v2][PR gdb/24052] Implement 'set print zero-values on|off' To: Hannes Domani , Gdb-patches References: <20200530161253.61299-1-ssbssa.ref@yahoo.de> <20200530161253.61299-1-ssbssa@yahoo.de> <1980167901.498897.1590883592361@mail.yahoo.com> <235118837.781199.1590937122739@mail.yahoo.com> From: Pedro Alves Message-ID: Date: Sun, 31 May 2020 16:21:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <235118837.781199.1590937122739@mail.yahoo.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2020 15:21:12 -0000 On 5/31/20 3:58 PM, Hannes Domani via Gdb-patches wrote: > Am Sonntag, 31. Mai 2020, 15:39:05 MESZ hat Pedro Alves Folgendes geschrieben: >> The thing is that an enum does not measure a quantity or offset. >> "0" has no usual particular significance compared to >> other enumerators.  While with pointers and integrals, usually >> "0" has significance, meaning no quantity, no offset or no object, >> or in general absence of the property being measured by the variable. >> >> For example, here's GDB's auto_boolean: >> >> /* * A generic, not quite boolean, enumeration.  This is used for >>      set/show commands in which the options are on/off/automatic.  */ >> enum auto_boolean >> { >>    AUTO_BOOLEAN_TRUE, >>    AUTO_BOOLEAN_FALSE, >>    AUTO_BOOLEAN_AUTO >> }; >> >> I'd think it confusing that "zero-values off" would hide >> AUTO_BOOLEAN_TRUE, but not AUTO_BOOLEAN_FALSE. >> >> Here: >> >> extern enum language_mode >>    { >>      language_mode_auto, language_mode_manual >>    } >> language_mode; >> >> What's the significance of hiding auto but not manual? >> >> Here: >> >> /* alignment enum */ >> enum ui_align >>    { >>      ui_left = -1, >>      ui_center, >>      ui_right, >>      ui_noalign >>    }; >> >> Why hide ui_center, instead of the other enumerators? >> >> Etc. > > It seems we have very different views about this. > I don't think it's confusing at all to hide AUTO_BOOLEAN_TRUE/ > language_mode_auto/ui_center in these cases. > OK, if such different views are both reasonable, then this normally means that the larger set of users will also contain people with such opposing views, which calls for making it optional. Maybe: set print zero-values all / non-enums / none > (For me it's more confusing that AUTO_BOOLEAN_TRUE is first in this enum.) > > If you don't want to hide it, just don't use -zero-values off. > Even the original reporter in the PR suggested only removing zero enums under an option: "Optionally also removing those enums which evaluate to zero would save even more unneeded information." >> (gdb) p g_out >> $1 = {pad1 = {c = 0 '\000', i = 0}, pad2 = {c = 0 '\000', i = 0}} >> (gdb) p out >> $2 = {pad1 = {c = 0 '\000', i = 0}, pad2 = {c = 0 '\000', i = 0}} >> >> (gdb) p -zero-values off -- g_out >> $3 = {} >> (gdb) p -zero-values off -- out >> $4 = {pad1 = {}, pad2 = {}} >> >> As you see, $3 and $4 gave different outputs, due to the padding. > > I agree that this might be weird, but I kinda see this as a feature. What's the value of the feature? I think it's a hard to justify feature, because garbage in padding happens randomly, and naturally, and doesn't affect the value at the language level. I very much question the value in wanting a different output here, and I hazard a guess that you were initially surprised with this case too. IMO it's just a bug not to consider it. >> Why print "static_field = 0" when zero-values is off? > > When printing structures, I usually don't care about the static members. > > And with -zero-values off it should just display the parts that have some kind > of value. > So now I kinda want to hide all static members when -zero-values off, no > matter what their real value is. NAK. Let's keep options orthogonal. Thanks, Pedro Alves