Fix possible infinite loop in message template parser + better handling incorrect templates

[304NotModified]

See #2557 (comment)

[codecov]

Codecov Report

Merging #2576 into master will increase coverage by <1%.
The diff coverage is 67%.

@@           Coverage Diff           @@
##           master   #2576    +/-   ##
=======================================
+ Coverage      81%     81%   +<1%     
=======================================
  Files         325     325            
  Lines       23908   23918    +10     
  Branches     3020    3022     +2     
=======================================
+ Hits        19385   19408    +23     
+ Misses       3707    3673    -34     
- Partials      816     837    +21

[304NotModified]

@snakefoot thanks for reviewing, I will react in this PR to make the discussions a bit more separated.

No need to use short (16 bit) since new processors prefer 32 bit and 64 bit variables.

This is a side effect hole.Index, which is already a 'short' (see

NLog/src/NLog/MessageTemplates/Hole.cs

Line 66 in 19de4fe

public readonly short Index;

)

Also no need to perform "safe" lookup, as invalid templates should trigger exceptions (just not unhandled exceptions)

What is the expected output of MessageTemplateParameters.Count with " {3} {4} {9} {8} {5} {6} {7}" ? It was 2, which was really unexpected for me. Also if we could make (partly) a good result, that really better then no result. e.g. in " {3} {4} {9} {8} {5} {6} {7}" we could maybe render 6 out of 7, which is better then 2 (and 0).

[snakefoot]

I prefer strict mode, but I can see Serilog has undocumented behavior when using invalid templates. Mixing strict with loose. P.S. Please don't make these constructors internal. See #2581 (Maybe remove one of the struct constructors, but the one with CaptureType is used by NLog.Extensions)

[304NotModified]

I prefer strict mode, but I can see Serilog has undocumented behavior when using invalid templates. Mixing strict with loose.

I prefer strict mode when:

• it's a compile error (not run-time)
• and/or it could be easily fixed (read: without recompile)
• if the non-strict mode has undefined behavior.