Daniel Stenberg wrote:
> On Sun, 22 Aug 2004, codemastr wrote:
>
>> I posted this a while ago. I never heard anything from anyone.
>
>
> I replied with a question, as the web archive shows:
>
> http://curl.haxx.se/mail/lib-2004-07/0162.html

[Quote]

> Do you have any idea what date string that was passed to curl_getdate()
> when this occured?

I see this with standard dates sent by Apache. One example of full
response headers:

--------------------------------------------------
  1 HTTP/1.1 200 OK
  2 Date: Mon, 23 Aug 2004 13:33:00 GMT
  3 Server: Apache/1.3.23 (Unix) (Red-Hat/Linux)
  4 Last-Modified: Thu, 29 Mar 2001 17:53:01 GMT
  5 ETag: "c423-b4a-3ac3767d"
  6 Accept-Ranges: bytes
  7 Content-Length: 2890
  8 Keep-Alive: timeout=15, max=100
  9 Connection: Keep-Alive
10 Content-Type: text/html
--------------------------------------------------

I have been seeing this as well since upgrading to curl 7.12.1. (I was
using some cvs snapshot from Dec 2003 earlier.)

It has been many years since I did any yacc, and I haven't yet really
had time to investigate too much, so take this with a pinch of salt ...
A little bit of cvs archeology led me to believe that this was caused by
some changes that made to the yacc date parsing code re-entrant. Those
changes converted some yacc internal variables from being global (and
hence zero-inited) to local. I suspect this is what is causing the
problem. I suppose an (approximate) diff will make things clearer :

-----------------------------------------------------------------------
--- getdate.c.orig
+++ getdate.c
@@ -641,12 +641,6 @@
  #endif
  #endif

- YYSTYPE yyval; /* the variable used to return */
- /* semantic values from the action */
- /* routines */
-
-
-
  int
  yyparse(YYPARSE_PARAM_ARG)
       YYPARSE_PARAM_DECL
@@ -686,6 +680,10 @@
  #endif
  #endif

+ YYSTYPE yyval; /* the variable used to return */
+ /* semantic values from the action */
+ /* routines */
+
    int yylen;

  #if YYDEBUG != 0

-----------------------------------------------------------------------

I am currently using the following workaround in the generated yacc code
to silence the warnings. It seems to work ok.

-----------------------------------------------------------------------
@@ -680,7 +680,7 @@
  #endif
  #endif

- YYSTYPE yyval; /* the variable used to return */
+ YYSTYPE yyval = {0}; /* the variable used to return */
                                 /* semantic values from the action */
                                 /* routines */
-----------------------------------------------------------------------

But I am not entirely sure about my analysis. And I havent looked at how
to fix it in the original yacc file instead of the generated C. So, this
is clearly insufficient. I am hoping someone more clueful will come up
with a more concrete explanation and fix. Any suggestions for a better
fix would be much appreciated.

Harshal
Received on 2004-08-23