From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13915 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jonny Grant Newsgroups: gmane.linux.lib.musl.general Subject: Re: C Annex K safe C functions Date: Mon, 4 Mar 2019 11:24:08 +0700 Message-ID: References: <20190227105050.GE21289@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="74237"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 To: musl@lists.openwall.com Original-X-From: musl-return-13931-gllmg-musl=m.gmane.org@lists.openwall.com Mon Mar 04 05:24:28 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1h0f9P-000JDd-B8 for gllmg-musl@m.gmane.org; Mon, 04 Mar 2019 05:24:27 +0100 Original-Received: (qmail 22167 invoked by uid 550); 4 Mar 2019 04:24:25 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 22149 invoked from network); 4 Mar 2019 04:24:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk-org.20150623.gappssmtp.com; s=20150623; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Xc4DR/dGfKP93sIXO46/jZt+yoK5gVCl1WEyZwFF6TE=; b=WbBqzbyAJHYkcyYuuDEYlaextKh1pE9gVnYQQNH8MIFYUl5Or/fdBo3RU2OrlDZCkF auwIEVu1Em6FyVrF0GPFF+zEe4i/Ao6JZM6TTruFq2B4y3O+ffouubiG5GdVpclb2N+N UazuOMxw4X3bKsVn3BKBxKbZi5YsErSkv+fNYaJjLfyLCLCUNPP0P7FaFFIAU5P+BGXF qjw076lf8HQv0UZFc+sMEOnPnjvFdpm+wXYGT+CMDb51+BGw/SQteVbCtnnqgFu1hMgt Kx7Y8NEq7SoPItP4RFMc7xV45Atc0imejzQygE/GtqlPZzMSHyCZzvRDiXeQCf6g1ysq 34Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Xc4DR/dGfKP93sIXO46/jZt+yoK5gVCl1WEyZwFF6TE=; b=m868ke/Hv2MDJE8cTv4IjwDs4Oz5kVEnHIhjt9FimMKyzyqWaVeWnUO8vjjetxipCE +lo41flwGaft1gb0JbYCW8Vsp47JXzehCXI8t7DGXn02QfQUGRCcQsfgQuRFNF0yuowJ WrqdmzH18jVcS7KsB8EiayKsC50JH0kuqRs2h2oiBqT47Ki5CNVJLFIT5gzipM5Y4X9O UFCno9jquCW95OHiTMe382JWSN/PiWJe+o4P8Jn/iAUbQW3Ey62WCCV9O0DoGWfg3GkP LhLFCFT0hC2u7tO8ORUswSnBR2TZDZv4rWDX8rhBcHqB1T8Jun4HxuJJTaG1Hg8AvrR6 jDSA== X-Gm-Message-State: APjAAAWsSQVvPx8EDdv0U4ANkjffqfvJYFOqfWBX1pVesQG4JYSXY8Ni VSza6VVHG1QQRT0m6f+Tt/2gfA== X-Google-Smtp-Source: APXvYqyItENUXmct2/3GeArqPjkcNSGA2IIWi2VRI1KGwLSA3tMkJ410caQ2DVt/4qI4Fc+RGNp7sQ== X-Received: by 2002:a17:902:b486:: with SMTP id y6mr18554318plr.104.1551673451866; Sun, 03 Mar 2019 20:24:11 -0800 (PST) In-Reply-To: <20190227105050.GE21289@port70.net> Content-Language: en-GB Xref: news.gmane.org gmane.linux.lib.musl.general:13915 Archived-At: Hi! On 27/02/2019 17:50, Szabolcs Nagy wrote: > * Jonny Grant [2019-02-27 10:30:52 +0700]: >> Not on the list, so please cc me in replies. >> Any plans to support Annex K? >> Those safe functions are great, strncpy_s etc > > i wonder why you think they are great, > if they are advertised anywhere as safe or > useful then that should be fixed. > > annex k is so incredibly broken and bad > that there is a wg14 paper about it > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm > > normally it's ok to add nonsense interfaces > for compatibility, but in this case there is > no widespread use and the api depends on global > state that causes implementation issues even > if we wanted to implement it. Thanks for your reply! Well I wouldn't disagree with experts. I should re-read that review though. However, I was not aware that these APIs have global state? (memset_s, memcpy_s, memmove_s, strcpy_s, strncpy_s, strcat_s, strncat_s, strtok_s, memset_s, strerror_s, strerrorlen_s, strnlen_s) - do they? strncpy_s is great, it avoids the bug in strncpy that could cause the buffer to not be terminated. It's better than the strlcpy BSD uses which truncates buffers. BSD/OS X supports memset_s etc, but does not support set_constraint_handler_s https://opensource.apple.com/source/Libc/Libc-1244.1.7/string/NetBSD/memset_s.c.auto.html FreeBSD seems to support memset_s https://www.freebsd.org/cgi/man.cgi?query=memset&sektion=3&apropos=0&manpath=freebsd Oracle Solaris supports Annex K https://docs.oracle.com/cd/E88353_01/html/E37843/strncpy-s-3c.html#scrolltoc If issues, I'd support amending Annex K, rather than removing. It's good they check for NULL/nullptr, they return errno_t directly instead of the errno global kludge. Sticking with old APIs forever is difficult, but no one uses creat() anymore either. Could I ask, does your libc follow POSIX spec to the letter? eg not checking pointers for NULL (where spec omits to mention checking pointers valid) ? eg this call which crashes glibc? puts(NULL); It looks like it will still SIGSEGV... https://git.musl-libc.org/cgit/musl/tree/src/stdio/puts.c Thanks Jonny