From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by hurricane.the-brannons.com (Postfix) with ESMTP id EAFF177AA5 for ; Sun, 2 Feb 2014 14:49:32 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta14.westchester.pa.mail.comcast.net with comcast id Mamc1n0010Fqzac5Eap4bn; Sun, 02 Feb 2014 22:49:04 +0000 Received: from eklhad ([107.5.36.150]) by omta08.westchester.pa.mail.comcast.net with comcast id Map41n00H3EMmQj3Uap4oW; Sun, 02 Feb 2014 22:49:04 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke User-Agent: edbrowse/3.4.10 Date: Sun, 02 Feb 2014 17:49:06 -0500 Message-ID: <20140102174906.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391381344; bh=V9a37DPt4qjUDNPd03I0WD22vTyQb+QfDRVs9MYL6eU=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=AKXyp3aThDZQm8EopoVH+dqDvMip3cRlULtisCYJguoTEKrZizKLC/Ofi2J2Au8jX wRQYzbj633nmekiVvy2LN71rYl9adxVlZ8WncPQXwEx6lzc/ildsOxuKxWjpyy1OIc oLCOx3PCnBIkJ0nQim3wzUXgEeF20+rjDDZ29vZEUJTFjfPoC2y5Qth80o/FUg/3IJ 1v+itsQPaP0pcDiJ+QiRs3jC1dUVnHDX+af13HB+4JkyFrQbZWVFmDiiuDnxl3+sHp TlBBSyJb9ORhC3or0VvmOQ6qa9Lup2CjXr/9SJ27uyM7BMrLPmua3Wln1Ruw8ZWrSy frRUVjO2bhz+Q== Subject: [Edbrowse-dev] What? How did this ever work? X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Karl Dahlke List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 22:49:33 -0000 Well this is really embarrassing. Open your Bible's please to html.cpp, function buildTagArray(). What does this do? When I parse the html page I build a link list of tag structures, one for each on the page. Then at the end, buildTagArray copies them over into one linear array for easy access. Now I can get my hands on tag[17] easily. But ... have a look at the structure htmlTag. It has this member. struct htmlTag *controller; This usually points to the form that owns the tag. So an input field, or a submit or reset button, or radio button, they all point back to the form that contains it. Ok but that's a pointer, and it points to the form tag that was put into my link list. When all those tags are copied over into the array, the pointers are not updated. They still point back to the structures in my link list. t->controller points to a structure that isn't even in the array. Why would this ever work? Probably because I made a second mistake, and never freed the structures in the link list. So those copies are still there. t->controller points to the old copy of
, which isn't the active copy, but is still around because I didn't free it. I still can't imagine this would work all the time. There must be some times when I am modifying the form tag in the array, and input fields are modifying the form tag in the link list, and they diverge, and results are not consistent. I have to think it will cause trouble eventually, in some hard to predict situations. Anyways, it's crazy. While I'm in here I have to rewrite all this stuff. The member should probably be int controller_idx; The index of the form tag in the array that owns this input field. A little more indirection, but it will always be right, even if the tag array is reallocated as it grows. And there are other static variables in html.cpp, like currentForm currentSel currentOpt etc that are pointers and could be invalid as their structures move about in memory. As I say, I can't believe it works at all. So leave html alone for a while, and I'll try to program some sanity back into it. Karl Dahlke