Am Wednesday 14 November 2012 schrieb David Ryskalczyk: > On Wed, Nov 14, 2012 at 8:31 AM, Tim Ruehsen <[email protected]> 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
