On Thu, Mar 31, 2016 at 10:36 AM, Elizabeth Mattijsen <l...@dijkmat.nl> wrote:
Advertising
> > The reasoning behind _not_ setting things via environment variables, is > that this means the programmer now needs to worry what e.g. the webserver > running the Perl program does, and there are unknown stability (and > possibly security) implications. This adds bloat to the program. > > > > The programmer is better off if they only explicitly need to worry about > it when they want to change the defaults. > > The environment variable is only used if there is no dynamic variable > found. So, if a programmer wishes to use a specific buffer size in the > program, they can. This is precisely _not_ addressing the issue I raised. This way, the programmer _needs_ to explicitly check whether the environment variable is set, and if not, somehow set a sensible default if the environment variable differs from the default. That adds quite a bit of unnecessary programming to each Perl program that deals with buffers. The status as it was before, was that the programmer didn't need to worry about the environment for buffer size. If a malicious environment sets the buffer size to something undesirable, there may be side effects that are hard to predict, and may have other implications than merely performance. I think it is preferable that the decision about that is made by the programmer rather than the environment. PS: I'm assuming that $*DEFAULT-READ-ELEMS is clean by the time it reaches any code, that is that it only contains _valid_ integer values and cannot lead to overflows or anything, I am not concerned about that. -- Jan
