From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88520 invoked by alias); 7 Apr 2016 12:29:32 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 88476 invoked by uid 89); 7 Apr 2016 12:29:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=risk, our, HContent-Transfer-Encoding:8bit X-HELO: mail-yw0-f175.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=sQJxQ0U7fTvY3CMTkViZiXvuBrR+7GDbnKfTR46ud00=; b=a0gCHKPNheq9plE80Tgf5eknywe+0tXpFtLU0TVhcmlrf7Vhf0q4Jtke5eosvwvnZv Glza9C2a3bs26IVOP+twE7+gWJIjWluW77g2NYSJ4ClTwFq+KGU/4Zg8gJks2Ei2goJG cqYTW5og+JuJxrjBKEHT+52PfuqSyAOOhxaf2Xgf3DfEBUfyynL0DeilIY7k9J52WqH3 0odgMcbbsNfkXXLn8cZ25mg/i5FM4tWw6o9DAoXOSCJeIOARI7sk6MW9nubBoLqGMmP0 NmcCfib5Bq5sh0opXeic/hc/SgKRyZHzacMTOUUkDvyQmO2wNkX4d7xiJRd+9Ib9x4rV euTw== X-Gm-Message-State: AD7BkJJx3z5qhG/AmeVFByhQkSeTqyuS0Yc6rIxAsSzF6XV4R8epOqj86Vnv1aKPixPRHzpw X-Received: by 10.37.34.5 with SMTP id i5mr1347844ybi.87.1460032159726; Thu, 07 Apr 2016 05:29:19 -0700 (PDT) Subject: Re: [PATCH 2/3] network: recvmsg and sendmsg standard compliance (BZ#16919) To: libc-alpha@sourceware.org References: <1459175641-12520-1-git-send-email-adhemerval.zanella@linaro.org> <1459175641-12520-3-git-send-email-adhemerval.zanella@linaro.org> <57062EC6.20504@redhat.com> <57064679.5000405@arm.com> From: Adhemerval Zanella Message-ID: <5706529D.8050101@linaro.org> Date: Thu, 07 Apr 2016 12:29:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <57064679.5000405@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SW-Source: 2016-04/txt/msg00102.txt.bz2 On 07-04-2016 08:37, Szabolcs Nagy wrote: > On 07/04/16 10:56, Florian Weimer wrote: >> On 03/28/2016 04:34 PM, Adhemerval Zanella wrote: >>> diff --git a/sysdeps/unix/sysv/linux/check_native.c b/sysdeps/unix/sysv/linux/check_native.c >>> index b3cbbe3..a8e447e 100644 >>> --- a/sysdeps/unix/sysv/linux/check_native.c >>> +++ b/sysdeps/unix/sysv/linux/check_native.c >>> @@ -111,10 +111,13 @@ __check_native (uint32_t a1_index, int *a1_native, >>> { >>> struct msghdr msg = >>> { >>> - (void *) &nladdr, sizeof (nladdr), >>> - &iov, 1, >>> - NULL, 0, >>> - 0 >>> + .msg_name = (void *) &nladdr, >>> + .msg_namelen = sizeof (nladdr), >>> + .msg_iov = &iov, >>> + .msg_iovlen = 1, >>> + .msg_control = NULL, >>> + .msg_controllen = 0, >>> + .msg_flags = 0 >>> }; >> >> The requirement for such changes always makes me nervous. If we have >> breakage in our own code, how many applications are affected? >> > > yes, it looks risky. > >> Note that the recvmsg manual page says “is defined as follows” about >> struct msghdr, not “contains the following members in some arbitrary order”. >> > > i think the man page should be more clear about > that the msg_controllen, msg_iovlen and cmsg_len > types conflict with posix. > > to prevent more non-portable code being written > based on the linux man page. > >> Is standards compliance here really worth this risk? >> >> (I do not have a strong opinion either way, I just want to raise this >> point.) >> >> Florian >> > I do not have a strong opinion as well, but I also do not see it a compelling reason to *not* follow the standard as well. I would follow Szabolcs suggestion and update the manual specifying to more portable way to access the structures is through designated initializers (which gcc accepts in c90 as well). Best option would be to get this fixed in kernel, but it is another thread.