MediaWiki r84782 - Code Review

Thanks for the extra statistics.

This is not really what I meant when I said "use snprintf". This code is fragile, still has lots of integer literals, and so could easily be changed by a naive future developer in a way that makes it insecure.

Here's what I meant:

• Make a buffer structure, which holds a data pointer, a current write pointer and a length.
• Make a wrapper for snprintf() which takes a pointer to a buffer structure as a parameter. It should calculate the remaining length, then call snprintf() to write to the current write position. It should then advance the current write position according to the number of bytes written.
• Make a global variable which holds such a buffer. Initialise its data pointer and length to the location of a large (say 64KB) fixed buffer. Then use this global buffer in the stats code.

I understand that this might be complicated, which is why I keep recommending the use of libevent I/O buffers.

There's no reason C code can't be secure, beautiful and readable. It's just a matter of good habits.

I think strtimeval() be better if it were rewritten to use ldiv().

http://www.cplusplus.com/reference/clibrary/cstdlib/ldiv/

Check out this time formatting code I wrote for another project:

    // Write timestamp
    ldiv_t d = {
      0,
      entry.timestamp
    };
    d = ldiv( d.rem, 3600000 );
    printZeroPad( Serial, d.quot, 4 ); // hours
    Serial.print( ':' );
    d = ldiv( d.rem, 60000 );
    printZeroPad( Serial, d.quot, 2 ); // minutes
    Serial.print( ':' );
    d = ldiv( d.rem, 1000 );
    printZeroPad( Serial, d.quot, 2 ); // seconds
    Serial.print( '.' );
    printZeroPad( Serial, d.rem, 3 ); // milliseconds
    Serial.print( ' ' );

What do you think? A number like 1/60 can't be precisely represented as a floating point number, so it's hard to verify that your code will always give the correct result.

total processing time: 188 days 4520h 57m 51.000000s
gained time: 2 days 62h 32m 52.859375s

Too many hours!

This is "nodeploy" only because it doesn't automatically get deployed with the rest of 1.19, but needs to be packaged and pushed.