Re: [Bug-wget] [PATCH] Invalid Content-Length header in WARC files, on some platforms

[Tim Ruehsen]

Am Wednesday 14 November 2012 schrieb David Ryskalczyk:
> On Wed, Nov 14, 2012 at 8:31 AM, Tim Ruehsen <address@hidden> wrote:
> > BTW, I had a private discussion with Guiseppe at April 13th 2012.
> > It was about C99/POSIX and using getline().
> > Guiseppe's last words were:
> > 
> > "I had to check it better before give an answer, but yeah, the answer is:
> > let's use C99 and POSIX-2008."
> > 
> > @Guiseppe: can you confirm this officially on the mailing list ?
> 
> I think C89 should be supported. There is also the aforementioned
> issue with Windows. Visual Studio supports portions of C99
> (specifically the ones that are also present in the newer C++
> standards), but not the whole thing.

Developing on Windows doesn't need MS Visual Studio / MS Visual C. There are 
alternatives like Intel's ICC or gcc that should both work with e.g. Eclipse.
As far as I can read from 
http://stackoverflow.com/questions/146381/visual-studio-support-for-new-c-c-
standards
some C99 features are supported by MSVC but that shouldn't even matter.

How long should C open source code be MS vendor locked-in ? Please just give 
me a number of years. I guess, hmmm... another 25 years ?
Even 1 year is too long, because MS already stated they won't implement (most) 
C99 features. The present, the future (and even the past 12 years) means C99 / 
POSIX compliancy for C programmers and C source code.

There should be much better arguments for C89 than MS Visual C not being C99 
compliant.
Just give me a few of them.

> From the comments in wget.h, it appears that the whole purpose of the
> wgint is to protect against this problem.
> 
> > /* Pick an integer type large enough for file sizes, content lengths,
> > 
> >    and such.  Because today's files can be very large, it should be a
> >    signed integer at least 64 bits wide.  This can't be typedeffed to
> >    off_t because: a) off_t is always 32-bit on Windows, and b) we
> >    don't necessarily want to tie having a 64-bit type for internal
> >    calculations to having LFS support.  */
> 
> The patch that was originally submitted makes the code in warc.c
> behave like the file_size(const char *filename) function in
> src/utils.c.

Just because someone did it in the past doesn't mean we must stick forever 
with it. Sounds a bit like "Uhhh, electric lights ? But those torches always 
served us right !". Maybe we could turn our heads to look ahead instead of 
looking back.

Sorry, this compatibility issue drives me a bit nuts. Nothing personal.

> --David Ryskalczyk

Regards, Tim