From owner-freebsd-arch@FreeBSD.ORG Thu Jul 31 21:31:24 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 637D4856; Thu, 31 Jul 2014 21:31:24 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF0D52A17; Thu, 31 Jul 2014 21:31:22 +0000 (UTC) Received: from BLUPR05CA006.namprd05.prod.outlook.com (10.255.219.164) by CO2PR05MB729.namprd05.prod.outlook.com (10.141.228.12) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 31 Jul 2014 21:31:20 +0000 Received: from BY2FFO11FD050.protection.gbl (2a01:111:f400:7c0c::138) by BLUPR05CA006.outlook.office365.com (2a01:111:e400:83f::36) with Microsoft SMTP Server (TLS) id 15.0.995.14 via Frontend Transport; Thu, 31 Jul 2014 21:31:19 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD050.mail.protection.outlook.com (10.1.15.187) with Microsoft SMTP Server (TLS) id 15.0.990.10 via Frontend Transport; Thu, 31 Jul 2014 21:31:19 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 31 Jul 2014 14:31:12 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s6VLUqn85662; Thu, 31 Jul 2014 14:31:09 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id s6VLUFSP097778; Thu, 31 Jul 2014 17:30:24 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201407312130.s6VLUFSP097778@idle.juniper.net> To: Poul-Henning Kamp Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML In-Reply-To: <58087.1406837257@critter.freebsd.dk> Date: Thu, 31 Jul 2014 17:30:15 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(189002)(199002)(164054003)(77982001)(99396002)(54356999)(107046002)(102836001)(20776003)(44976005)(50466002)(83072002)(47776003)(69596002)(46102001)(85852003)(86362001)(92566001)(68736004)(92726001)(87936001)(83322001)(50986999)(76482001)(48376002)(4396001)(84676001)(6806004)(81342001)(21056001)(97736001)(81542001)(53416004)(95666004)(85306003)(106466001)(110136001)(31966008)(79102001)(103666002)(76506005)(105596002)(74502001)(80022001)(81156004); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB729; H:P-EMF02-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0289B6431E Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; X-OriginatorOrg: juniper.net Cc: sjg@freebsd.org, arch@freebsd.org, John-Mark Gurney , marcel@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 21:31:24 -0000 Poul-Henning Kamp writes: >Can I point discreetely at sbuf(3)'s accumulative error handling >and suggest that libxo does something similar ? That way applications >only need to check for errors once, rather than after every single >call to every single function in the libxo library. sbuf looks like a simple case, returning either ENOMEM or the error code from the flush function. libxo can keep a "there's been an error" flag that the user can retrieve, but all the details of what's gone wrong would be lost. Or it can buffer the contents of warning messages and deliver it to the caller. Currently you need to turn on the per-handle XOF_WARN flag to get warnings displayed; perhaps that's enough. Thanks, Phil