connect.c compilation problems on irix
Dear all, I've found an odd problem with compiling wget 1.9 on irix 6.5 (same thing happens in the development branch but seems specific to irix) - the compilation of connect.c fails with a parsing error: /usr/bin/cc -I. -I. -I/usr/local/include -DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"/usr/local/etc/wgetrc\" -DLOCALEDIR=\"/usr/local/share/locale\" -O -c connect.c cc-1065 cc: ERROR File = connect.c, Line = 330 A semicolon is expected at this point. socklen_t sa_len = sockaddr_len (); ^ cc-1148 cc: ERROR File = connect.c, Line = 331 Expression must have "struct" or "union" type. if (getsockname (msock, &srv.sa, &sa_len) < 0) (this happens with both cc and gcc) A little digging reveals that the preprocessor is replacing the token "sa_len" with "sa_union . sa_generic . sa_len2" such that the following code from bindport (bind_local in development branch): socklen_t sa_len = sockaddr_len (); if (getsockname (msock, &srv.sa, &sa_len) < 0) becomes: socklen_t sa_union . sa_generic . sa_len2 = sockaddr_len (); if (getsockname (msock, &srv.sa, &sa_union . sa_generic . sa_len2) < 0) and causes the observed parsing problem. However, I can't find a macro (or even another mention!) for sa_len defined anywhere, so presume it must be some strange combination of preprocessor directives on irix (I'm not an expert in this kind of thing, though). In any case, modifying connect.c to use a name other than sa_len fixes it so everything compiles, but obviously it would be much better to find the real cause of the problem: Index: connect.c === RCS file: /pack/anoncvs/wget/src/connect.c,v retrieving revision 1.27.2.1 diff -r1.27.2.1 connect.c 330,331c330,331 < socklen_t sa_len = sockaddr_len (); < if (getsockname (msock, &srv.sa, &sa_len) < 0) --- > socklen_t sa_lion = sockaddr_len (); > if (getsockname (msock, &srv.sa, &sa_lion) < 0) (and for development branch: Index: connect.c === RCS file: /pack/anoncvs/wget/src/connect.c,v retrieving revision 1.59 diff -r1.59 connect.c 442,443c442,443 < socklen_t sa_len = sockaddr_size (sa); < if (getsockname (sock, sa, &sa_len) < 0) --- > socklen_t sa_lion = sockaddr_size (sa); > if (getsockname (sock, sa, &sa_lion) < 0) ) If anyone has any thoughts on this, I'd love to hear them! Cheers, Dan.
Re: connect.c compilation problems on irix
Dan Staines <[EMAIL PROTECTED]> writes:
> A little digging reveals that the preprocessor is replacing the
> token "sa_len" with "sa_union . sa_generic . sa_len2"
Adorable. :-)
> However, I can't find a macro (or even another mention!) for sa_len
> defined anywhere, so presume it must be some strange combination of
> preprocessor directives on irix (I'm not an expert in this kind of
> thing, though). In any case, modifying connect.c to use a name other
> than sa_len fixes it so everything compiles, but obviously it would
> be much better to find the real cause of the problem:
You found the real cause all right. The IRIX header files define
sa_len (a member in a structure, I forget which one) to a macro, so
access to structure elements *looks* like it's accessing an sa_len
element, whereas in fact it's in fact accessing a union. This is all
very nice until you try to name a variable "sa_len".
Here's a fix, against the current CVS. (I applied a similar fix to
the 1.9 branch as well.) Thanks for the report.
2003-11-27 Hrvoje Niksic <[EMAIL PROTECTED]>
* connect.c (bind_local): Rename sa_len to addrlen because IRIX
headers define sa_len as a macro.
Index: src/connect.c
===
RCS file: /pack/anoncvs/wget/src/connect.c,v
retrieving revision 1.60
diff -u -r1.60 connect.c
--- src/connect.c 2003/11/26 17:20:23 1.60
+++ src/connect.c 2003/11/27 10:56:48
@@ -447,8 +447,8 @@
/* If *PORT is 0, find out which port we've bound to. */
if (*port == 0)
{
- socklen_t sa_len = sockaddr_size (sa);
- if (getsockname (sock, sa, &sa_len) < 0)
+ socklen_t addrlen = sockaddr_size (sa);
+ if (getsockname (sock, sa, &addrlen) < 0)
{
/* If we can't find out the socket's local address ("name"),
something is seriously wrong with the socket, and it's
a problem on wgetting a PNG image
Hi I am not sure if this is a bug, but it's really out of my expectation. Here is the way to reproduce the problem. 1. Put the URL http://ichart.yahoo.com/b?s=CSCO into the browser and then drag out the image. It should be a file with .png extension. So I believe this is PNG. (is it?!?) 2. wget -O csco.img "http://ichart.yahoo.com/b?s=CSCO"; Originally, I thought that the files obtained in either way should be the same. But the fact is that they are of different sizes. From the 2nd file's header, it's a gif instead. This is the bigger file. Does it mean that wget has transformed the original file? Or did I miss any step? Pl help! : ) Albert
Re: a problem on wgetting a PNG image
"|| It's a bird ||" <[EMAIL PROTECTED]> writes: > Does it mean that wget has transformed the original file? Don't worry, Wget didn't perversely transform the image it downloaded. What happens is that the server checks which user agent you are using and sends PNG's only to those that it thinks can handle it. Fortunately, it is not hard to fool the server into thinking Wget can "handle" PNG's. For example: $ wget 'http://ichart.yahoo.com/b?s=CSCO' [...] Length: unspecified [image/gif] [ <=> ] 22,536 9.31K/s However: $ wget 'http://ichart.yahoo.com/b?s=CSCO' -U 'Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703' [...] Length: unspecified [image/png] [ <=> ] 4,005 7.54K/s 17:03:31 (7.52 KB/s) - `b?s=CSCO' saved [4005]
Re: a problem on wgetting a PNG image
[EMAIL PROTECTED] wrote: > I am not sure if this is a bug, but it's really out of my expectation. > > Here is the way to reproduce the problem. > > 1. Put the URL http://ichart.yahoo.com/b?s=CSCO into the browser and > then drag out the image. It should be a file with .png extension. So I > believe this is PNG. (is it?!?) > > 2. wget -O csco.img "http://ichart.yahoo.com/b?s=CSCO"; > > Originally, I thought that the files obtained in either way should be > the same. But the fact is that they are of different sizes. From the > 2nd file's header, it's a gif instead. This is the bigger file. > > Does it mean that wget has transformed the original file? Or did I > miss any step? The server changes its behavior based on the user agent. The following will get back an image/gif: wget http://ichart.yahoo.com/b?s=CSCO while the following will get back an image/png: wget http://ichart.yahoo.com/b?s=CSCO -U "Mozilla/4.0 (compatible)" Tony
Re[2]: a problem on wgetting a PNG image
Hi Tony, Thanks for your advice. I have tried the --user-agent option also. It works now. : ) Albert Friday, November 28, 2003, 2:58:53 AM, you wrote: TL> [EMAIL PROTECTED] wrote: >> I am not sure if this is a bug, but it's really out of my expectation. >> >> Here is the way to reproduce the problem. >> >> 1. Put the URL http://ichart.yahoo.com/b?s=CSCO into the browser and >> then drag out the image. It should be a file with .png extension. So I >> believe this is PNG. (is it?!?) >> >> 2. wget -O csco.img "http://ichart.yahoo.com/b?s=CSCO"; >> >> Originally, I thought that the files obtained in either way should be >> the same. But the fact is that they are of different sizes. From the >> 2nd file's header, it's a gif instead. This is the bigger file. >> >> Does it mean that wget has transformed the original file? Or did I >> miss any step? TL> The server changes its behavior based on the user agent. The following will TL> get back an image/gif: TL> wget http://ichart.yahoo.com/b?s=CSCO TL> while the following will get back an image/png: TL> wget http://ichart.yahoo.com/b?s=CSCO -U "Mozilla/4.0 (compatible)" TL> Tony
