Re: fprintf, snprintf, etc., %n and overflow on the return value

2017-05-23 Thread Vincent Lefevre
On 2017-05-23 10:11:35 +0700, Robert Elz wrote: > Date:Tue, 23 May 2017 02:10:23 +0200 > From:Vincent Lefevre > Message-ID: <20170523001023.ga19...@zira.vinc17.org> > > | If the intent were to have "int" everywhere related to sizes in the >

Re: fprintf, snprintf, etc., %n and overflow on the return value

2017-05-22 Thread Robert Elz
Date:Tue, 23 May 2017 02:10:23 +0200 From:Vincent Lefevre Message-ID: <20170523001023.ga19...@zira.vinc17.org> | If the intent were to have "int" everywhere related to sizes in the | printf context, then why is the second argument of

Re: fprintf, snprintf, etc., %n and overflow on the return value

2017-05-22 Thread Shware Systems
The second argument is size_t because this relates to allocatable RAM, which is a limitation for snprintf. If there was an nprintf, using ofs_t as type I'd consider appropriate. Using int for the argument type of * is something all implementations can support, whether it's range is wider or not

Re: fprintf, snprintf, etc., %n and overflow on the return value

2017-05-22 Thread Vincent Lefevre
On 2017-05-22 19:55:22 -0400, Shware Systems wrote: > I feel strtoi, or atoi, is appropriate because when * is used the > associated argument is of type int, not any integer type or > intmax_t, limiting the string representation too if they're to have > the same range. The argument associated

Re: fprintf, snprintf, etc., %n and overflow on the return value

2017-05-22 Thread Shware Systems
I feel strtoi, or atoi, is appropriate because when * is used the associated argument is of type int, not any integer type or intmax_t, limiting the string representation too if they're to have the same range. Perhaps this should be explicit too somewhere. The C standard has the same ambiguity,

Re: fprintf, snprintf, etc., %n and overflow on the return value

2017-05-22 Thread Vincent Lefevre
On 2017-05-22 17:10:08 -0400, shwares...@aol.com wrote: > The expected behavior is nothing gets written, since the size_t n > argument is 0. Whether *() gets written to or not is ambiguous. > The implied behavior is that since it is only checking what the > buffer length should be, by the

Re: fprintf, snprintf, etc., %n and overflow on the return value

2017-05-22 Thread SHwareSyst
The expected behavior is nothing gets written, since the size_t n argument is 0. Whether *() gets written to or not is ambiguous. The implied behavior is that since it is only checking what the buffer length should be, by the paragraph at line 31022, any %n is ignored since no output is

fprintf, snprintf, etc., %n and overflow on the return value

2017-05-22 Thread Vincent Lefevre
I'm wondering what behavior is expected for the following program on a machine with 32-bit int's and 64-bit long's: #include int main(void) { long n = -1; snprintf (NULL, 0, "%1000s%ln", "", ); printf ("%ld\n", n); return 0; } i.e. in case of overflow on the return value