This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 11/29/2016 09:56 AM, Martin Sebor wrote:
On 11/28/2016 05:42 PM, Joseph Myers wrote:On Sun, 27 Nov 2016, Martin Sebor wrote:Finally, the patch also tightens up the constraint on the upper bound of bounded functions like snprintf to be INT_MAX. The functions cannot produce output in excess of INT_MAX + 1 bytes and some implementations (e.g., Solaris) fail with EINVAL when the bound is INT_MAX or more. This is the subject of PR 78520.Note that failing with large bounds is questionable (there is an apparent conflict between ISO C, where passing a large bound seems valid, and POSIX, where large bounds require errors; see <http://austingroupbugs.net/view.php?id=761>; I'm not sure if any liaison issue for this ever got passed to WG14).Thanks! That's useful background. Let me check with Nick to see is he (as the POSIX/WG14 liaison) plans to submit it. I can also write it up for the next WG14 meeting if we or the Austin Group feel like WG14 should clarify or change things.
I've been looking at the original BSD sources where snprintf came from (AFAICT). The first implementation I could find is in Net/2 from 1988. It returns EOF when the size after conversion to int is less than 1. The same code is still in 4.4BSD. Early UNIX implementations also have the limitation that the buffer size maintained by struct FILE is an int. Since snprintf on these early implementations usually uses vfprintf to do the work (with the count being set to the snprinf bound), it can't store more than INT_MAX bytes without overflowing the counter. http://minnie.tuhs.org/cgi-bin/utree.pl?file=Net2/usr/src/lib/libc/stdio/snprintf.c It looks to me like the POSIX spec is faithful to the historical implementations and C should consider either tightening up its constraints or make the behavior implementation-defined to allow for more modern implementations that don't have this restriction. Martin
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |