From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 14 16:03:00 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B5DDE1; Sun, 14 Dec 2014 16:03:00 +0000 (UTC) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E4B69DF9; Sun, 14 Dec 2014 16:02:59 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id EF7E1B806E; Sun, 14 Dec 2014 17:02:56 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id DCE7828494; Sun, 14 Dec 2014 17:02:56 +0100 (CET) Date: Sun, 14 Dec 2014 17:02:56 +0100 From: Jilles Tjoelker To: Stefan Esser Subject: Re: [Patch] updated: Add JSON and XML output to pciconf (libxo support - D1206) Message-ID: <20141214160256.GB84077@stack.nl> References: <201412101931.sBAJV7uk076028@idle.juniper.net> <548BF6EF.2090504@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <548BF6EF.2090504@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hackers@freebsd.org" , Phil Shafer X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 16:03:00 -0000 On Sat, Dec 13, 2014 at 09:21:03AM +0100, Stefan Esser wrote: > Am 10.12.2014 um 20:31 schrieb Phil Shafer: > > Stefan Esser writes: > >> But I have to admit, that I do not really know the rules for > >> quotes around data fields in JSON. (E.g. must I write "true" > >> to represent a string value of "true", or could I also use > >> true without quotes to represent a truth value? What do > >> parsers do if there are unquoted words or words separated > >> by blanks?) > > JSON uses "true", "false", and "null" (without quotes) > > as unquoted tokens. If you want a boolean, you'll need: > > xo_emit("{n:valid/%s}", valid ? "true" : "false"); > Hmmm, but what will the "reader" of the JSON file expect? > Is it good practice to have libxo output booleans instead > of strings, if these are the only possible values? > Will a JSON parser automatically convert them to strings, > if an unquoted true or false is read and a strings is > expected? > (Sorry, I have bno experience with JSON parsers ...) It depends on which JSON parser. Each parser and language has its own rules about type conversion. Some examples: When using JavaScript JSON.parse, JavaScript's type conversion rules will apply when using the deserialized data. These will never implicitly convert a string "true" or "false" to a boolean true or false (both of them will convert to true because they are non-empty). A boolean will be converted to a string "true" or "false" when appropriate. Likewise, when using Python json module, Python's type conversion rules will apply when using the deserialized data. These will generally allow few implicit conversions, but as in JavaScript any non-empty string will be considered true by control flow statements. Explicit conversion of a boolean to a string gives "True" or "False"; something like "true" if v else "false" is needed to get the lowercase values. Jansson (C library) and Android's JsonReader do not convert any types at all. If multiple types are acceptable, the caller will have to handle it. JSONObject (Java, from json.org or in Android) will convert a string "true" or "false" from and to a boolean true or false when it is requested as such type. Summarizing, a boolean will be easiest to use if it is serialized as a JSON boolean. If you do not want to use a JSON boolean for some reason, a number 0 (false) or 1 (true) will still be easier and safer than a string "false" or "true". -- Jilles Tjoelker