headers
Daniel Stenberg | 1 Mar 2004 08:27
Picon
Favicon

[autobuild] those FreeBSD warnings

Hi (Joe)

I'm looking at your FreeBSD build:

	http://curl.haxx.se/auto/log.cgi?id=20040301010441-1578

All those warnings are the same ones, which gcc finds in a system header. Can
you check if these warnings are caused by the -Wundef option?

I'd like to switch off whatever option it is that is causing your gcc version
to report these warnings in the system headers.

(and *thanks* for setting up and running this for us!)

--

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
Permalink | Reply | 7 comments |
headers
Daniel Stenberg | 1 Mar 2004 08:57
Picon
Favicon

better links in the online man pages

Hey

I just thought I'd point out that I did some minor adjustments of 'roffit'
last week, and now the libcurl man pages feature links between them when the
man pages mention other libcurl functions/man pages. It makes them easier to
browse around in, methinks.

The HTML pages in the release archives should also have these links, I hope!
;-)

(All we need to do in the man pages to make them appear, is to keep referring
to other functions in the man pages, using the \fIcurl_foo(3)\fP syntax.)

--

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
Permalink | Reply | 0 comments |
headers
Russ Freeman | 1 Mar 2004 10:37

CURLE_GOT_NOTHING - some (useful?) info.

Hi,

A customer of mine reported the following. I don't know anything about it
but I figured that it may help find out what causes it and maybe a solution
will come:

On investigation, I found that the TCP-IP receive window size on my PC was
8K.  I'm using Windows 2000, and I thought the default was supposed to be
16K.  So I decided to increase it to 16K.  Whilst looking at my TCP-IP
settings, I also noticed that the MTU value was not specified, so I set this
to 576 (for a dial-up connection).  I then added all of my DigiGuide
channels again, and the update worked.

Regards
Russ Freeman

t: 01395 272555
f: 01395 272555
e: russf <at> gipsymedia.com

=================
http://www.digiguide.com/ - World's best interactive TV guide
http://www.mydigiguide.com/ - The world's best online TV guide
http://library.digiguide.com/ - Massive free resource of TV information 
Permalink | Reply | 0 comments |
headers
Daniel Stenberg | 1 Mar 2004 11:08
Picon
Favicon

RE: removing winsock 2 dependence

On Thu, 26 Feb 2004, David Byron wrote:

> I've attached a new patch now that Daniel has committed the other MSVC
> changes (thank you).

Forgive my ignorance, but is this patch still valid after the discussions that
followed regarding IPv6 on Windows etc?

--

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
Permalink | Reply | 0 comments |
headers
Daniel Stenberg | 1 Mar 2004 11:13
Picon
Favicon

Re: http resume

On Wed, 25 Feb 2004, Eduardo =?iso-8859-1?Q?García?= wrote:

>          I have extracted calls to libcurl from my code and I am attaching a
> little test source reproducing 'the bug'. The test sample begins to download
> a file:  http://www.bitcomet.com/achive/BitComet_0.44.exe and aborts the
> download after at least 4000 bytes. If you run it again it checks the
> partially downloaded size and resumes the download after it has got 8000
> bytes at least, and then aborts it again.  The sample dumps libcurl verbose
> info for both attemps, so you can check headers and bytes downloaded.

Can you please provide such headers here in a mail instead? Your source code
was severly windowsified and I would rather not sit and adjust it to build on
my systems when you already have the info I could use to understand your
problem!

>          The result is 'the bug' again: headers messages (in dumps) shows
> correctly resumed download commands, but resumed bytes are always from the
> beginning of the file, an not from resume point as headers show.

Can you show us?

>          But I have got another strange behaviour while running it one and
> another in order to be sure of it as a good sample for you: Once I have
> completely downloaded the file on other disk-file ("Save as" in a
> web-explorer) in order to compare the downloads, the second run of the
> sample (resume) doesn't work, it cannot download even a byte and libcurl
> (curl_easy_perform) returns CURLE_HTTP_RANGE_ERROR.

Trying to resume a download of an already downloaded used to cause that bug,
because you can't request a range for a file that is beyond the file's size.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tor Arntsen | 1 Mar 2004 14:13
Picon
Favicon

AIX SSL autobuilds -- getting there

http://curl.haxx.se/auto/log.cgi?id=20040301134740-636

I finally managed to install an stunnel version on AIX that seems to
work somewhat (got it from Bull).  My earlier attempts always resulted
in all SSL curl tests failing.  I'm completely baffled by how stunnel
is supposed to work, I can't even get the examples in the manpages to
work, even on systems where I *know* that stunnel itself is working 
(because curl ssl tests are ok) :-)

In this autobuild only test 509 failed, but I'm not sure if I can figure 
out the problem (see above).  I do all my tunnelling through ssh, which 
is territory I understand much better :-)

-Tor
Permalink | Reply | 2 comments |
headers
Daniel Stenberg | 1 Mar 2004 14:40
Picon
Favicon

Re: AIX SSL autobuilds -- getting there

On Mon, 1 Mar 2004, Tor Arntsen wrote:

> I finally managed to install an stunnel version on AIX that seems to work
> somewhat (got it from Bull).  My earlier attempts always resulted in all SSL
> curl tests failing.  I'm completely baffled by how stunnel is supposed to
> work, I can't even get the examples in the manpages to work, even on systems
> where I *know* that stunnel itself is working (because curl ssl tests are
> ok) :-)

stunnel is somewhat of a mystery. I can't claim much knowledge there either. I
once wrote the test suite to run with an older version of stunnel (which was
easier to use) and later on "kromJx" made it work with the newer version (too)
and its config file concept. "It Just Works" ;-)

Partly because of this reason, I still haven't been able to provide a proper
test FTPS server that supports the new "correct" FTPS protocol that curl
speaks these days.

> In this autobuild only test 509 failed, but I'm not sure if I can figure
> out the problem (see above).

I'm CC'ing Peter Sylvester because of this, because he wrote the test and in
fact the particular part of the code this tests!

Can you run this test stand-alone and provide some details form the files in
log/ ?

(We really should improve testcurl.sh to provide info from the log/ dir when
test cases fail to make it easier to debug problems in cases such as this.)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Stenberg | 1 Mar 2004 15:01
Picon
Favicon

int64 printf format specifier in MSVC?

Hey

What's the %-flag for printf() to print a int64 variable when using MSVC?

I'm reverting the idea of using '%Od' for curl_off_t printf()ing, and I am
now going for:

 curl_off_t size=1000;
 printf( CURL_FORMAT_OFF_T, size);

... where CURL_FORMAT_OFF_T is properly defined in curl/curl.l next to the
code that typedefs the variable.

For POSIX-systems with large file support, CURL_FORMAT_OFF_T will be %lld.

This makes it easier for app coders to printf() the variables using non-curl
printf()s and it will stop compilers from warning on our custom %Od stuff. The
curl printf code supports %lld, and I'd want it to support the MSVC way too
(if possible, otherwise I'll redefine the define for internal libcurl
purposes).

--

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
Permalink | Reply | 1 comment |
headers
Tor Arntsen | 1 Mar 2004 15:29
Picon
Favicon

Re: ares: fd_set on AIX

>From: tor <at> spacetec.no (Tor Arntsen)
>Date: Mon, 23 Feb 2004 16:44:53 +0100

Funny, I got this one from the mailing list just now, rather delayed..

-Tor
Permalink | Reply | 0 comments |
headers
Gisle Vanem | 1 Mar 2004 15:40
Picon
Favicon
Gravatar

Re: int64 printf format specifier in MSVC?

> What's the %-flag for printf() to print a int64 variable when using MSVC?
> 
> I'm reverting the idea of using '%Od' for curl_off_t printf()ing, and I am
> now going for:
> 
>  curl_off_t size=1000;
>  printf( CURL_FORMAT_OFF_T, size);
> 
> ... where CURL_FORMAT_OFF_T is properly defined in curl/curl.l next to the
> code that typedefs the variable.
> 
> For POSIX-systems with large file support, CURL_FORMAT_OFF_T will be %lld.

Under Windows, the print formatting is done by MSVCRT.DLL which is
used by MSVC and MingW. Watcom and Digital Mars uses their own
RTL, but they all support "%I64d". I'm not sure if "%Ld" is also supported
by all.

--gv
Permalink | Reply | 0 comments |

Gmane