Sender: richdawe AT bigfoot DOT com Message-ID: <3A0C59A8.9DB02164@bigfoot.com> Date: Fri, 10 Nov 2000 20:25:12 +0000 From: Richard Dawe X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.17 i586) X-Accept-Language: de,fr MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: Summary of the snprintf() situation References: <3A09EAB9 DOT 6924045A AT bigfoot DOT com> <3A0B329F DOT D33F7737 AT bigfoot DOT com> <7458-Fri10Nov2000111820+0200-eliz AT is DOT elta DOT co DOT il> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0277DA47BD951DC32BB7C40F" Reply-To: djgpp-workers AT delorie DOT com This is a cryptographically signed message in MIME format. --------------ms0277DA47BD951DC32BB7C40F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello! Eli Zaretskii wrote: > It's been a long time since that discussion, and I have a bad habit of > forgetting minor details, so please take what I say below with a grain > of salt. 8) > > Richard Dawe wrote: > > > > > Eli Zaretskii wrote: > > > > > > Why do we need to get to negative values of _cnt at all? We could > > > simply leave alone the _cnt member of the FILE object for _IOSTRG > > > ``streams''. > > > > I have to admit, reading this again, I am confused by what you say, > > Eli. If you don't track the position in the buffer using _cnt, what > > do you use? > > p->_cnt is not used for tracking the position, it is only used to know > how much more free space do we have in p->_buf. To track the buffer > position, we use p->_ptr; see the code above. By 'p->_buf', I guess you mean 'p->_base'. As it stands, the snprintf() code does not set up p->_base. So if we do not use p->_cnt, this will need fixing. > > Maybe I have an idea that will work. The intention of returning EOF is > > to stop _cnt wrapping round. > > I think that returning EOF should be a sign of some error. What error > do we have here, that we need EOF? The EOF as an error was to inform the caller that the counter had wrapped round. If we avoid the wrap-around, then we don't need to return EOF. > > _cnt is an int, whereas snprintf()'s buffer size > > is a size_t. Firstly, change _cnt to a ssize_t. Then place a > > restriction on the maximum buffer size, namely the maximum (positive) > > number that can be stored in both a size_t and ssize_t. Now, what > > error to return, when the buffer size is bigger than this? > > Are you trying to solve the problem of the argument n being too large? Yes, that is the problem. > If so, how does this relate to _cnt being negative? If n is too large, then _cnt (an int) will be negative if you just put n (a size_t) into it (actually n - 1 to leave space for nul). Therefore I suggest we put a restriction on n, to avoid this (and hence wrap-around & returning EOF). Things are pretty clear in my mind now. Maybe I will get time to produce some patches on Sunday. Then the code can do the talking. Thanks, bye, Rich =] -- Richard Dawe [ mailto:richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ ] --------------ms0277DA47BD951DC32BB7C40F Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIHFQYJKoZIhvcNAQcCoIIHBjCCBwICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BY0wggLMMIICNaADAgECAhB2D2twnX9wqhegGKLtJkJmMA0GCSqGSIb3DQEBBAUAMFgxJzAl BgNVBAoTHkJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYzEtMCsGA1UECxMkQlQgVHJ1 c3R3aXNlIC0gQ2xhc3MgMSBJbmRpdmlkdWFsIENBMB4XDTAwMTAxNTAwMDAwMFoXDTAxMTAx NTIzNTk1OVowggERMScwJQYDVQQKEx5Ccml0aXNoIFRlbGVjb21tdW5pY2F0aW9ucyBwbGMx LTArBgNVBAsTJEJUIFRydXN0d2lzZSAtIENsYXNzIDEgSW5kaXZpZHVhbCBDQTFGMEQGA1UE CxM9d3d3LnRydXN0d2lzZS5jb20vcmVwb3NpdG9yeS9SUCBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVs bCBTZXJ2aWNlMRUwEwYDVQQDEwxSaWNoYXJkIERhd2UxIzAhBgkqhkiG9w0BCQEWFHJpY2hk YXdlQGJpZ2Zvb3QuY29tMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMJ3LQ1fxlYpzsChuJ16 J9dwyZIkhexC8uW2RGyxJVOG6643weIDoATk515qu8G91CS85rLDRFIB0u2N4ezCUCkCAwEA AaMgMB4wCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCB4AwDQYJKoZIhvcNAQEEBQADgYEA llCoL5Afa66m9bxGh/gMgwUCCCOb6DdKHmJw9Q5h0xoEHuHOcEEjNPqQug5ZQaKioEIJM7DS gsuSPrEy5Z521OzNWxN8nRv9YAlV3fVHQxcNlsjaAZru6zJxZ0+0uAKKFKOjJLTdfXFUqdcH kcY2syIZo6DRSIap9pCqC+HYOoIwggK5MIICIqADAgECAhEA0zBJnvKZLVDb03kHStQNPTAN BgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x NzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkwHhcNOTgwMjEyMDAwMDAwWhcNMDMwMjEyMjM1OTU5WjBYMScwJQYDVQQKEx5Ccml0aXNo IFRlbGVjb21tdW5pY2F0aW9ucyBwbGMxLTArBgNVBAsTJEJUIFRydXN0d2lzZSAtIENsYXNz IDEgSW5kaXZpZHVhbCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0QG30oEW28L0 Z/5fC03tfZ+a2ahBQYehZ6hrcb1PW6ZIXuqm5y8KpzYJ9rLhRkMA3BzH8eACTVhkn/qAJmqC m2GTDa7eueV8q6A/0I/p9KwahkjEgG4exysZ9svlo21+HWn0yFtrHAraKuNoZOPpFnNP5dOp AuObV5lKytU5AlkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYL YIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQBS Acma9vqkvYS4miXj6t5jPDVao9pIjdxWTjRoiRPRRi7wz0On9jUzqVK8sVcrPIpwxmvnlOyv jM8KpZaJVXECrgclfNlGR58eSiyTSHyBO0XUK4XLJkwkBXyBmiHc+32l5gvC+QXuGccUEdg8 WZ/OOeoRMbCdGuw1+LeE55h4JzGCAVAwggFMAgEBMGwwWDEnMCUGA1UEChMeQnJpdGlzaCBU ZWxlY29tbXVuaWNhdGlvbnMgcGxjMS0wKwYDVQQLEyRCVCBUcnVzdHdpc2UgLSBDbGFzcyAx IEluZGl2aWR1YWwgQ0ECEHYPa3Cdf3CqF6AYou0mQmYwCQYFKw4DAhoFAKB9MBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMTExMDIwMjUxMlowHgYJKoZI hvcNAQkPMREwDzANBggqhkiG9w0DAgIBKDAjBgkqhkiG9w0BCQQxFgQUVhqY+g7bwv6+ds4a V1fLIiLClaowDQYJKoZIhvcNAQEBBQAEQFJGHy7Y5o+/354ZuohC02FW9hPwN2Xex2MZEVGS cOdLH9AhxVdWVpuaE4fUqcMv0bTyFcyQ5UtWbCDjEyyGNrk= --------------ms0277DA47BD951DC32BB7C40F--