Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com Message-Id: <199905032225.RAA14517@modi.xraylith.wisc.edu> X-Authentication-Warning: modi.xraylith.wisc.edu: localhost.xraylith.wisc.edu [127.0.0.1] didn't use HELO protocol To: Corinna Vinschen cc: cygwin-developers AT sourceware DOT cygnus DOT com Subject: Re: (fixed patch) "%E" formatting for the humans In-reply-to: Your message of "Mon, 03 May 1999 23:47:55 +0200." <372E198B DOT C2FDEFE2 AT cityweb DOT de> Date: Mon, 03 May 1999 17:25:14 -0500 From: Mumit Khan Corinna Vinschen writes: > Mumit Khan wrote: > > [...] > > + * NOTE: Currently there is no policy for how long the > > + * the buffers are, and looks like 256 is a smallest one > > + * (dlfcn.cc). Other than error 1395 (length 213) and > > + * error 1015 (length 249), the rest are all under 188 > > + * characters, and so I'll use 189 as the buffer length. > > + * For those longer error messages, FormatMessage will > > + * return FALSE, and we'll get the old behaviour such as > > + * ``Win32 error 1395'' etc. > > + */ > > + const int bufferlen = 189; > > [...] > > Regards, > > Mumit > > Consider other native language versions of the system. E.g. german > expressions are longer than english one's in the most cases. > The reason I limited the buffer size here is that I don't much about how the various char buffers are scattered throughout winsup, and didn't want to introduce a subtle bug due to overruns. My scheme is very safe in that it will get the proper error messages as long as it fits within the supplied buffer, and if it doesn't, fall back on the old-style message. Someone with more experience with/time on winsup should be able to track all the various buffer sizes and then just adjust this limit accordingly. Regards, Mumit