This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc 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]

Re: MAXPACKET changes and Netscape java-vm


As Jakub pointed out, using tiny stack sizes with glibc is already asking
for trouble and they are just lucky that nothing but this bit them.

But to answer your question, there are two different kinds of fixes that
could be done instead.  One is simply to use malloc for the 64k buffer, or
adaptively use alloca or malloc based on stack size as Jakub suggested.
The other way is to use truncated results and carefully audit the code to
be sure that it never returns bogus results or allows buffer overruns when
an absurdly huge packet comes in.  However, future protocol revisions we
may implement will increase the maximum reasonable size of a real response,
so the issue of a large buffer size would come back then.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]