bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tim Ruehsen
Subject: Re: [Bug-wget] [PATCH] Invalid Content-Length header in WARC files, on some platforms
Date: Mon, 26 Nov 2012 09:06:51 +0100
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

Am Saturday 24 November 2012 schrieb Ángel González:
> Stephanie Rühsen schrieb:
> > Am Samstag, 24. November 2012 schrieb Ángel González:
> >> The 22 is a magic number, based in the fact
> >> that 1e21 > INT64_MAX
> >> 
> >> I think it should be #defined in wget.h
> >> 
> >> It could be defined variable depending on the
> >> different MAX values, eg. sizeof( STRINGIZE( INT64_MAX ) )
> > 
> > I found INT64_MAX in stdint.h. AFAIK, it is c99 !?
> > You don't deserve c99 featurs, do you ? ;-)
> 
> Don't worry, there's also the pre-c99 <limits.h> :)

???
I just checked my ~10 years old SuSE 7.3 system:
gcc version is 2.95.3, but it alrerady has <stdint.h> with INT64_MAX defined.
The define is not in <limits.h> !

AFAIK, many C99 features where derived from gcc extensions.

Just my opinion:
For GNU licenced projects, I tend to use GNU extensions (especially nested 
functions to have something like lambda functions / closures). I don't really 
care for other compilers - if they are not gcc compatible, they are out.
Intel, IBM and some others do understand this...
LLVM/clang has BLOCKS (but I still didn't find out where to find the qsort() 
(et. al.) function that takes a block as 4th param).

That especially holds true for an official GNU tool like Wget !
Ignorant ? yes, sometimes...

Tim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]