From owner-freebsd-arch@FreeBSD.ORG Fri Aug 1 20:28:17 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 482A3A32; Fri, 1 Aug 2014 20:28:17 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE1D228D; Fri, 1 Aug 2014 20:28:16 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id B717F1578; Fri, 1 Aug 2014 20:28:09 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id s71KS7u9063133; Fri, 1 Aug 2014 20:28:08 GMT (envelope-from phk@phk.freebsd.dk) To: Phil Shafer Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML In-reply-to: <201408011550.s71FoiQo003612@idle.juniper.net> From: "Poul-Henning Kamp" References: <201408011550.s71FoiQo003612@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <63131.1406924887.1@critter.freebsd.dk> Date: Fri, 01 Aug 2014 20:28:07 +0000 Message-ID: <63132.1406924887@critter.freebsd.dk> Cc: arch@freebsd.org, John-Mark Gurney , marcel@freebsd.org, "Simon J. Gerraty" 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: Fri, 01 Aug 2014 20:28:17 -0000 -------- In message <201408011550.s71FoiQo003612@idle.juniper.net>, Phil Shafer writes: >"Simon J. Gerraty" writes: >>Of course I wouldn't be surprised if the lib already handles all that ;-) > >No, I can't manufacture memory on the fly ;^) > >Hmmm... I could have an emergency mode where I stop trying to buffer >and churn out a series of small write() calls to send close tags. >Or perhaps just punting and refusing to write more once ENOMEM is >seen is the right thing. First of, this is not just ENOMEM, this is also invalid UTF-8 strings, NULL pointers and much more bogosity. >Seeing broken output is better than limping >along with output that looks right but isn't. The output should preferably be explicitly broken, so that nobody downstream mistakenly takes it and runs with it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.