[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fe0cc4d2-aa67-b2b5-d4e9-62f5683efc66@jguk.org>
Date: Mon, 4 Mar 2019 11:24:08 +0700
From: Jonny Grant <jg@...k.org>
To: musl@...ts.openwall.com
Subject: Re: C Annex K safe C functions
Hi!
On 27/02/2019 17:50, Szabolcs Nagy wrote:
> * Jonny Grant <jg@...k.org> [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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
