Hello Axel, Axel Beckert schrieb/wrote:
>> in https://bugs.debian.org/807836 it was discovered that the Zsh builtin >> "unlimit" has potential unforeseen side-effects. >> >> An easy to reproduce case for the problem is documented in >> https://bugs.debian.org/807836#30 > > That example is IMHO a wrong usage of awk then. If the consuming > script isn't capable of parsing scientific notation but uses a tool > which produces scientific notation if needed, that's for sure not > zsh's fault. > >> The problem here is that unlimit sets the maximum input size to s.th. that >> is by >> far out of the feasibility of the hardware being used. > > So what. Bash does similar things: > > $ ulimit -v -m > virtual memory (kbytes, -v) unlimited > max memory size (kbytes, -m) unlimited > > I'm sure even with swap, there's no unlimited virtual memory available > on my machine. That is my main point. I think the "real problem" here is the definition of a "hard limit". My definition of a "hard limit" is either the maximum physical capability of the hardware being used, or a subset of that when a admin sets a hard limit via e.g. /etc/security/limits.conf . ...and not some random value without any meaning. Obviously YMMV So i do not blame anyone, i just ask for clarification on: i How is unlimit designed to work. ii Improved its documentation to match that design, so that potentially users of unlimit have a chance to reliable decide whether unlimt is for them. Hint: /usr/share/doc/zsh-common/examples/zshrc.gz contains "unlimit" and thats iirc is the place where i got it from. Nor from that example file nor from manpage one can have a glimpse of the real impact that unlimit has for runtime. Again i do not blame anyone and i certainly will not jump into a potential flame war over "how to write good code". It is just that i had fallen into a trap which could have been avoided with more information about the consequences of unlimit. > I'm sorry, but if code is broken by too big integer values or > unexpected by used scientific notation, it's not valid code but broken > code. I second that. But that is an other bug. kind regards, Thilo
