From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3346 invoked by alias); 16 Oct 2016 01:47:15 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 39649 Received: (qmail 25107 invoked from network); 16 Oct 2016 01:47:15 -0000 X-Qmail-Scanner-Diagnostics: from mercury.zanshin.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(64.84.47.142):SA:0(0.0/5.0):. Processed in 0.316926 secs); 16 Oct 2016 01:47:15 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) Date: Sat, 15 Oct 2016 18:14:44 -0700 (PDT) From: Bart Schaefer Reply-To: zsh-workers@zsh.org To: zsh-workers@zsh.org Subject: Re: type-checking for metafiedness? (was: Re: Cores almost on demand in patcompile()) Message-ID: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) X-Face: "f/X=UCVgd*^c>+x(gMq0at?e:woX+;'snkkRzc3SX<0AZ (/PS4.M2hzGS9X:Qj]at_H/%a9K}:-eS<"v_7vX84PG9Bf Zpb`wI!I4geY=or+nWq`3CX`oq&TJR;g^ps|7(MH?jh;bs %vHJfCh5>a*6Re5m|Bidja\\o]>n\A)ib1:yX*T`zR(*h~ %tOw<~!D9{e6h!8M2:d8G2@K>y^1I_Vdy\d\MYe]z7c MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII [I originally sent this 12 hours ago but it still hasn't shown up in the mailing list archives. Seems to be problems with mail from the gmail web interface again. Sorry if this eventually appears multiple times.] On Sat, Oct 15, 2016 at 1:30 AM, Daniel Shahaf wrote: > > Does anyone have a way to get type checking that doesn't involve > adding .v everywhere? Wouldn't it suffice to use typedef char *unmeta_t; typedef unsigned char *meta_t; (or the reverse if we believe we're mostly going to be working on meta_t). If we do that and also enable the GCC warnings -Wtype-limits -Wconversion -Wformat-signedness would we not get adequate verbosity without changing pointer arithmetic and dereferencing? I hadn't even considered all the places where using a struct would change memory allocation strategy. Oof.