From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-103519-e=80x24.org@sourceware.org>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS31976 209.132.180.0/23
X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2
Received: from sourceware.org (server1.sourceware.org [209.132.180.131])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by dcvr.yhbt.net (Postfix) with ESMTPS id 53AC41F461
	for <e@80x24.org>; Mon,  8 Jul 2019 16:06:51 +0000 (UTC)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:cc:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=jj/Z/1Lie86njFXF
	50Yvjau7Fi4giR/C+xYXdsq/qrT+OCgXB4jrde1XgCfSkmj072n5y4FBp3a19IOl
	d3FwECgiQC95OLhfv3AZPuosYy+yC86meFY0T8LU2iQXx7kbm3ebSWAKD/you5fr
	mwZrg6thw8hWjDWaqVeLHjHNGTk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:cc:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=MSfeHdud+rhhzolLxmMMSs
	Opp3A=; b=RmFVeg5rqb2J5/994QacMdWjkf16o3B0lIGiwPrFW4+w/Fb/bLOD2b
	stBI/crRQXirZ12tf5j6qZIgd/iTGb4Jxsrj3IAX/LOstKkKVLpBsyiv7cisO0Os
	PaQbla6P/LN7yvi3L5UtlgXEMlm9eJ/0ky8RrwKV6Gol9r6LYwnx4=
Received: (qmail 128745 invoked by alias); 8 Jul 2019 16:06:49 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Unsubscribe: <mailto:libc-alpha-unsubscribe-e=80x24.org@sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 128736 invoked by uid 89); 8 Jul 2019 16:06:48 -0000
Authentication-Results: sourceware.org; auth=none
X-HELO: zimbra.cs.ucla.edu
Subject: Re: glibc at the Toolchains microconference at LPC 2019
To: Florian Weimer <fweimer@redhat.com>, Maciej Rozycki <macro@wdc.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
References: <87o92kibdz.fsf@oldenburg2.str.redhat.com>
 <alpine.DEB.2.20.1906271839080.11773@tpp.hgst.com>
 <87y318r8eb.fsf@oldenburg2.str.redhat.com>
From: Paul Eggert <eggert@cs.ucla.edu>
Message-ID: <ca7b4e82-38b6-399f-2858-289ea4143588@cs.ucla.edu>
Date: Mon, 8 Jul 2019 09:06:42 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <87y318r8eb.fsf@oldenburg2.str.redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Florian Weimer wrote:
> When it comes to exposes the system call, we prefer to use size_t for
> buffer sizes (even if the kernel uses int or unsigned int), purely for
> documentation purposes.

I suggest using "ssize_t or size_t" to keep the text parallel with "int or 
unsigned int". We shouldn't insist on size_t for buffer sizes when the natural 
interpretation of the value is signed (as in the return value for 'read' etc.) 
or is too large for malloc etc.