Sender:	richdawe AT bigfoot DOT com
Message-ID:	<3A0C59A8.9DB02164@bigfoot.com>
Date:	Fri, 10 Nov 2000 20:25:12 +0000
From:	Richard Dawe <richdawe AT bigfoot DOT com>
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>
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--

- Raw text -