From: Sam S. <sd...@gn...> - 2016-08-31 13:55:34
|
> * Daniel Jour <qnavry.bregjvt@tznvy.pbz> [2016-08-31 13:57:12 +0200]: > >> BUFSIZ is a pretty standard constant for all string buffers. > > Eh, can you support that? It's a standard constant for STREAM > buffers. This is even defined by the C (C99) standard. Using it for > anything that's not directly related to a stream thus seems wrong to > me. > > The only thing that might be interpreted as "standard for [..] string > buffers" is this quote from the glibc documentation: > >> Sometimes people also use BUFSIZ as the allocation size of buffers >> used for related purposes, such as strings used to receive a line of >> input with fgets (see Character Input). There is no particular >> reason to use BUFSIZ for this instead of any other integer, except >> that it might lead to doing I/O in chunks of an efficient size. yes, this is precisely what I was talking about. > Though this too does not specify whether BUFSIZ will be small enough > to be put onto the stack. Moreover it's just in the documentation of a > single libc, there might be systems that have a huge BUFSIZ but only > provide limited stack space. BUFSIZ is usually page size (4kB). Given the amount of legacy code which does what glibc documentation talks about, we are in a good company. This is the same issue as /bin/pwd - if it ain't broke, don't fix it. Unless there is a commonly used clearly correct alternative approach, the "char buffer[BUFSIZ];" is going to stay with us, If it will ever be replaced, it will be a pervasive change throughout the CLISP sources, not just the regexp module. -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1404 http://www.childpsy.net/ http://memri.org http://truepeace.org http://honestreporting.com http://openvotingconsortium.org People with a good taste are especially appreciated by cannibals. |