[
https://issues.apache.org/jira/browse/THRIFT-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-6173.
--------------------------------
Fix Version/s: 0.25.0
Assignee: Jens Geyer
Resolution: Fixed
> Haxe TFullDuplexHttpClient is dead code: guarded by an undefined conditional
> and does not compile
> -------------------------------------------------------------------------------------------------
>
> Key: THRIFT-6173
> URL: https://issues.apache.org/jira/browse/THRIFT-6173
> Project: Thrift
> Issue Type: Bug
> Components: Haxe - Library
> Reporter: Jens Geyer
> Assignee: Jens Geyer
> Priority: Minor
> Fix For: 0.25.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{lib/haxe/src/org/apache/thrift/transport/TFullDuplexHttpClient.hx}} is dead
> code and has been since it was added.
> h4. It is compiled out on every target
> The file body is wrapped in {{#if swf}}. The Haxe Flash target defines
> {{flash}}, not {{swf}}, so the guard never holds. Verified both ways with
> Haxe 4.2.1:
> * a {{#if swf}} block containing a deliberate type error compiles clean under
> {{-swf}} (the block is skipped);
> * the same block written as {{#if flash}} fails with the expected type error.
> So the class body has never been compiled, on any target.
> h4. It would not compile if the guard were corrected
> Changing the guard to {{#if flash}} and compiling for {{-swf}} gives, in
> order:
> * line 181: {{Type not found : Function}}
> * line 240: {{Type not found : Error}}
> * {{private var obuffer : Bytes = new Bytes();}} (and {{CRLF}}, and
> {{chunkSize}} in {{read()}}) -- {{Not enough arguments, expected length:Int,
> b:haxe.io.BytesData}}
> * {{chunkSize.writeByte(...)}} -- {{haxe.io.Bytes}} has no {{writeByte}}
> method
> h4. Context
> The class came in with THRIFT-2644 (2014) as a port of the ActionScript 3
> library, whose own version traces back to THRIFT-1223 / THRIFT-2391. It is
> referenced nowhere else in the tree, appears in no build file, and is not
> exercised by CI. {{haxelib.json}} publishes the whole {{src}} tree via
> {{classPath}}, so it ships in the haxelib package without ever being built.
> Its target runtime, Adobe Flash, reached end of life on 2020-12-31.
> Removing the file requires no build-file changes.
> Related, but not a duplicate: THRIFT-669 asks for chunk-encoded full-duplex
> HTTP in the Java library. Nothing in this issue affects that request.
> Noticed while sweeping the HTTP transports across bindings for unbounded
> header accumulation. The chunk-size loop in this class does accumulate
> without bound, which is what drew attention to it -- but since the code is
> unreachable on every target, that is not a defect anyone can reach, and this
> ticket is plain housekeeping rather than a correctness or security fix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
