- 04 Mar, 2019 6 commits
-
-
Nils Goroll authored
Ref #2899
-
Nils Goroll authored
Ref #2859 #1799
-
Nils Goroll authored
Ref #2859
-
Nils Goroll authored
Ref #1799
-
Nils Goroll authored
In order to avoid the cross product problem with conversion functions (from x to y types would require x*y functions), we add flexibility regarding the input parameters to conversion functions: Each convertion function named after the destination type now takes all sensible arguments by name. int is named integer because of the reserved symbol name "int" in C. All functions should be fully backwards compatible (existing vtcs continue to work), but compile time checks are now effectively removed. The conversion functions now trigger vcl errors if used incorrectly or if conversion errors occur and no failback is provided. However, if a failback is provided, vcl errors are only raised for usage errors. For consistency, the conversion functions now only ever truncate if necessary. std.round() is added for explicit rounding where required. Existing functions which are now obsolete are marked deprecated. Ref #2899 Ref https://github.com/varnishcache/varnish-cache/wiki/VIP12:-vmod-polymorphism-(for-type-conversions)
-
Poul-Henning Kamp authored
I have reimplemented this based on Nils's #2858, because I found it too complex and intrusive. (In particular we try to avoid unions in Varnish). Testcase m00051 by: Nils Goroll Closes: #2858
-
- 03 Mar, 2019 9 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
It may have sounded like it's been added for the first time.
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
- 01 Mar, 2019 1 commit
-
-
Federico G. Schwindt authored
-
- 27 Feb, 2019 4 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
the previous code would round 9007199254740991 to 9007199254740992 Tested on linux and the four vtest SunOS variants
-
Nils Goroll authored
vtest would segfault due to a null pointer access on empty headers
-
Poul-Henning Kamp authored
Closes #2905
-
- 26 Feb, 2019 9 commits
-
-
Nils Goroll authored
we missed to change these when we changed the VCL_INT typedef from long to int64_t Should we add VCL_INT_MAX / VCL_INT_MIN (and for the other integer types, respectively)?
-
Nils Goroll authored
-
Nils Goroll authored
Ref: doc/README.WRITING_RST.rst
-
Nils Goroll authored
in particular: - remove defintion lists (Description/Example) - examples as code blocks:: - argument names as *emphasis* - ``literals`` Ref: doc/README.WRITING_RST.rst
-
Nils Goroll authored
Spotted by @lkarsten
-
Lasse Karstensen authored
This commit attempts to make it easier to read build output, and hopefully makes configure.ac easier as well. -Wall has already been added around line 645, no need to add it twice. On GCC -Wreturn-type is a part of -Wall, which we enable elsewhere. https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html On Clang -Wreturn-type is enabled by default: https://clang.llvm.org/docs/DiagnosticsReference.html#wreturn-type Same with -Wswitch as -Wreturn-type, so that can be removed as well. Finally, use spaces instead of tabs to make cc output shorter and more readable.
-
Nils Goroll authored
-
Nils Goroll authored
I did consider generalizing VCL_IterDirector which handles backend iterations for the CLI, but found the complications not worth the savings for such a trivial function.
-
Dridi Boukelmoune authored
-
- 25 Feb, 2019 6 commits
-
-
Poul-Henning Kamp authored
-
Nils Goroll authored
Thank you, @Dridi - yes, allocations outside the lock were motivated by minimizing the critical section, but n_backend could actually change, so this was wrong. As we use an RW lock, doing more work under it should only have marginal impact. - n_backend == 0 is probably best handled as a special case
-
Dridi Boukelmoune authored
With that, (almost) only libvgz carries goto statements from zlib. This isn't changing any of the previous semantics, in particular the AN(be) assertion from the "ok:" jump is honored by all code paths formerly leading to it. Previously, the bitmap was allocated on the stack prior to the magic check of shardd, which is now fixed at the expense of a potential code style violation. But more importantly, we currently read the number of backends prior to acquiring the read lock, but there is no evidence that this was done on purpose and not overlooked, besides moving a possibly expensive state initialization outside of the critical section. If that was on purpose, please document it.
-
Geoff Simmons authored
References #2912
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
- 23 Feb, 2019 3 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Nils Goroll authored
-
- 22 Feb, 2019 2 commits
-
-
Nils Goroll authored
things I seem to only notice in my email reader...
-
Nils Goroll authored
Previously, we did not test for the storage being actually freed and freeing only happened for passes, either explicit or a hit on hfm or hfp, but not the for the object becoming the hfm/hfp. We now handle incremental freeing for hfm/hfp as for private objects and add a test which actually checks that storage is being freed on the go. Fixes #2653
-