From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 019ED21666 for ; Thu, 20 Jun 2024 00:55:01 +0200 (CEST) Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Wed Jun 19 18:53:25 -0400 2024 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1718837572; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2NCgRDvgtk/Ji0o/7Z28chKSiNpkxfLCDEurupagaAo=; b=aQKVnWeHvAPb6NxNgVYTgKc0OEh8UXNDwar7vkAJwYFBp27wpAG1gMAOjML5sNBaAlqmkV kh6SJtyzWXcLld0zTW0DIxj86XG23xVjXTC3/mUR5z1sann9qBqtswcspebmW/esL58sXB dSiqpOjqBSyDMcH/vkjhJMHAxEjRLPM= Received: from [192.168.168.200] ( [207.45.82.38]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 3f5d1e80 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Wed, 19 Jun 2024 17:52:52 -0500 (CDT) Message-ID: Date: Wed, 19 Jun 2024 17:53:23 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: 9front@9front.org References: <306905B856E05E4082518070A9498919@smtp.pobox.com> Content-Language: en-US From: Jacob Moody In-Reply-To: <306905B856E05E4082518070A9498919@smtp.pobox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: NoSQL plugin base cache optimizer Subject: Re: [9front] [PATCH] upas: allow send to parse e-mail descriptions like marshal Reply-To: 9front@9front.org Precedence: bulk On 6/18/24 13:05, Romano wrote: > Ping. Here's a cleaned up patch: > http://okturing.com/src/20104/body > > Similarly with the ramfs patch, any comments/concerns? The general idea seems fine I think. I don't use upas, but I did find some issues with the implementation purposed: +char * Typical style is to make the return type 'char*' here +userfrom(char *cp) +{ + char *s; + int n; + + if((n = strlen(cp)) > 4 && cp[n-1] == '>'){ + if((s = strrchr(cp, '<')) != nil && s != cp && isspace(s[-1])) { + s++; + cp[n-1] = '\0'; + strcpy(cp, s); I don't love this loop, we're essentially walking the string three times here. Once for the first strlen, again for strrchr, and a third time with the strcpy. Because we return a pointer here we could get rid of this strcpy entirely and just make this inner block two lines like so: + cp[n-1] = '\0'; + return s + 1; However at this point we'd still be walking the string twice. I wanted to see if we could just walk the string once without having the code suck and this is what I came up with: char* userfrom(char *cp) { char *p, *e; if((p = strchr(cp, '<')) == nil) return cp; if(p == cp || !isspace(p[-1])) return cp; p++; if((e = strchr(p, '>')) == nil) return cp; *e = '\0'; return p; } Not that the length is going to be super long here, but being a bit more efficient doesn't make the code any more complicated (imo). Also I believe the commit message is incorrect given it's understanding of what printform is doing. I pulled the code out to play with it, and from what I see when it is given a "A name " it will print out the full thing, not just the email. The point of this code seems to ensure that the "name" portion of this description is passed through the rfc2047fmt function (installed as %U). /sys/src/cmd/upas/marshal/marshal.c:820 Specifically prints both portions there, with the only difference from the default case being that it passes the name through %U. So I think the description of what is going on in the commit message is not quite correct either. Thanks, moody