[jira] [Updated] (THRIFT-1331) Ruby library deserializes an empty map to nil

2011-09-07 Thread Armaan Sarkar (JIRA) 

 [ 
https://issues.apache.org/jira/browse/THRIFT-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Armaan Sarkar updated THRIFT-1331:
--

Attachment: THRIFT-1331_v3.patch

Sorry, wrong patch. Here's the final one.

> Ruby library deserializes an empty map to nil
> -
>
> Key: THRIFT-1331
> URL: https://issues.apache.org/jira/browse/THRIFT-1331
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.7, 0.8
>Reporter: Armaan Sarkar
>Assignee: Armaan Sarkar
> Attachments: THRIFT-1331_v1.patch, THRIFT-1331_v2.patch, 
> THRIFT-1331_v3.patch
>
>
> The problem occurs when deserializing an empty map. Instead of deserializing 
> to an empty hash in Ruby, Thrift currently makes it a nil object. This poses 
> a variety of problems and is not the intended/original behavior. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1331) Ruby library deserializes an empty map to nil

2011-09-07 Thread Armaan Sarkar (JIRA) 

 [ 
https://issues.apache.org/jira/browse/THRIFT-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Armaan Sarkar updated THRIFT-1331:
--

Attachment: THRIFT-1331_v2.patch

Thanks for catching the .should. Here's a patch that fixes that. 
It turns out this is just restricted to the Compact Protocol which saves a few 
bytes by not writing metadata (key and value types) when serializing an empty 
map. 

> Ruby library deserializes an empty map to nil
> -
>
> Key: THRIFT-1331
> URL: https://issues.apache.org/jira/browse/THRIFT-1331
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.7, 0.8
>Reporter: Armaan Sarkar
>Assignee: Armaan Sarkar
> Attachments: THRIFT-1331_v1.patch, THRIFT-1331_v2.patch
>
>
> The problem occurs when deserializing an empty map. Instead of deserializing 
> to an empty hash in Ruby, Thrift currently makes it a nil object. This poses 
> a variety of problems and is not the intended/original behavior. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (THRIFT-962) Tutorial page on our website is really unhelpful

2011-09-07 Thread Jake Farrell (JIRA) 

 [ 
https://issues.apache.org/jira/browse/THRIFT-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jake Farrell reassigned THRIFT-962:
---

Assignee: Jake Farrell

> Tutorial page on our website is really unhelpful
> 
>
> Key: THRIFT-962
> URL: https://issues.apache.org/jira/browse/THRIFT-962
> Project: Thrift
>  Issue Type: Task
>  Components: Tutorial, Website
>Reporter: Bryan Duxbury
>Assignee: Jake Farrell
>
> It's just a weak skeleton. I mean, really, really weak.
> At the very least, we should point to TRUNK/tutorial/ for where to look at 
> code examples. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1331) Ruby library deserializes an empty map to nil

2011-09-07 Thread Michael Stockton (JIRA) 

[ 
https://issues.apache.org/jira/browse/THRIFT-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099248#comment-13099248
 ] 

Michael Stockton commented on THRIFT-1331:
--

s/struct == struct2/struct.should == struct2/

This affects more than compact protocol so you may want to add tests to 
struct_spec and union_spec instead.

> Ruby library deserializes an empty map to nil
> -
>
> Key: THRIFT-1331
> URL: https://issues.apache.org/jira/browse/THRIFT-1331
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.7, 0.8
>Reporter: Armaan Sarkar
>Assignee: Armaan Sarkar
> Attachments: THRIFT-1331_v1.patch
>
>
> The problem occurs when deserializing an empty map. Instead of deserializing 
> to an empty hash in Ruby, Thrift currently makes it a nil object. This poses 
> a variety of problems and is not the intended/original behavior. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Build failed in Jenkins: Thrift-cpp #153

2011-09-07 Thread Apache Jenkins Server 
See 

Changes:

[bryanduxbury] THRIFT-1328. java: TBaseHelper.toString(...) appends ByteBuffer 
data outside of valid buffer range

This patch now correctly considers both arrayOffset and position when 
determining how to access the backing array of a buffer.

Patch: Andy Schlaikjer

--
[...truncated 459 lines...]
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT THttpTransport.lo -MD -MP -MF .deps/THttpTransport.Tpo -c 
src/transport/THttpTransport.cpp -o THttpTransport.o >/dev/null 2>&1
mv -f .deps/THttpTransport.Tpo .deps/THttpTransport.Plo
/bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../..  -I/usr/include -I./src -Wall -Wextra -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overflow -Werror -Wall -Wall -Wextra -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror -MT THttpClient.lo 
-MD -MP -MF .deps/THttpClient.Tpo -c -o THttpClient.lo `test -f 
'src/transport/THttpClient.cpp' || echo './'`src/transport/THttpClient.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT THttpClient.lo -MD -MP -MF .deps/THttpClient.Tpo -c 
src/transport/THttpClient.cpp  -fPIC -DPIC -o .libs/THttpClient.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT THttpClient.lo -MD -MP -MF .deps/THttpClient.Tpo -c 
src/transport/THttpClient.cpp -o THttpClient.o >/dev/null 2>&1
mv -f .deps/THttpClient.Tpo .deps/THttpClient.Plo
/bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../..  -I/usr/include -I./src -Wall -Wextra -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overflow -Werror -Wall -Wall -Wextra -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror -MT THttpServer.lo 
-MD -MP -MF .deps/THttpServer.Tpo -c -o THttpServer.lo `test -f 
'src/transport/THttpServer.cpp' || echo './'`src/transport/THttpServer.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT THttpServer.lo -MD -MP -MF .deps/THttpServer.Tpo -c 
src/transport/THttpServer.cpp  -fPIC -DPIC -o .libs/THttpServer.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT THttpServer.lo -MD -MP -MF .deps/THttpServer.Tpo -c 
src/transport/THttpServer.cpp -o THttpServer.o >/dev/null 2>&1
mv -f .deps/THttpServer.Tpo .deps/THttpServer.Plo
/bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../..  -I/usr/include -I./src -Wall -Wextra -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overflow -Werror -Wall -Wall -Wextra -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror -MT TSocket.lo -MD 
-MP -MF .deps/TSocket.Tpo -c -o TSocket.lo `test -f 'src/transport/TSocket.cpp' 
|| echo './'`src/transport/TSocket.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT TSocket.lo -MD -MP -MF .deps/TSocket.Tpo -c 
src/transport/TSocket.cpp  -fPIC -DPIC -o .libs/TSocket.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror 
-Wall -Wall -Wextra -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overflow 
-Werror -MT TSocket.lo -MD -MP -MF .deps/TSocket.Tpo -c 
src/transport/TSocket.cpp -o TSocket.o >/dev/null 2>&1
mv -f .deps/TSocket.Tpo .deps/TSocket.Plo
/bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../..  -I/usr/include -I./src -Wall -Wextra -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overflow -Werror -Wall -Wall -Wextra -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overflow -Werror -MT TSSLSocket.lo -MD 
-MP -MF .deps/TSSLSocket.Tpo -c -o TSSLSocket.lo `test -f 
'src/transport/TSSLSocket.cpp' || echo './'`src/transport/TSSLSocket.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include -I./src -Wall 
-Wextra -peda

[jira] [Commented] (THRIFT-1330) PHP Namespaces no longer generated

2011-09-07 Thread Jake Farrell (JIRA) 

[ 
https://issues.apache.org/jira/browse/THRIFT-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099204#comment-13099204
 ] 

Jake Farrell commented on THRIFT-1330:
--

THRIFT-1241 introduced the php namespaces, would make sense to set the NS_ROOT 
with older style namespace for php classes < 5.3. If you would like to provide 
a patch for this that would be great, otherwise i can tackle it after some of 
the other tickets i have

> PHP Namespaces no longer generated
> --
>
> Key: THRIFT-1330
> URL: https://issues.apache.org/jira/browse/THRIFT-1330
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Compiler
>Affects Versions: 0.7, 0.8
> Environment: Mac OS X 10.6.8, CentOS 5.6, Ubuntu 11.04
>Reporter: B Armstrong
>Assignee: Jake Farrell
>Priority: Critical
>
> PHP namespaces are not being generated, ever. PHP 5.3 namespace aren't 
> generated either.
> The following will illustrate the bug. This works in Thrift 0.6.*
> $ thrift -version
> Thrift version 0.7.0
> $ cat > test.thrift
> namespace php TestNamespace
> struct ItemX {}
> $ thrift --gen php test.thrift
> $ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
> echo "NO NAMESPACE FOUND"
> NO NAMESPACE FOUND
> $ thrift -version
> Thrift version 0.8.0-dev
> $ thrift -gen php test.thrift 
> $ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
> echo "NO NAMESPACE FOUND"
> NO NAMESPACE FOUND

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1328) TBaseHelper.toString(...) appends ByteBuffer data outside of valid buffer range

2011-09-07 Thread Hudson (JIRA) 

[ 
https://issues.apache.org/jira/browse/THRIFT-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099197#comment-13099197
 ] 

Hudson commented on THRIFT-1328:


Integrated in Thrift #252 (See [https://builds.apache.org/job/Thrift/252/])
THRIFT-1328. java: TBaseHelper.toString(...) appends ByteBuffer data 
outside of valid buffer range

This patch now correctly considers both arrayOffset and position when 
determining how to access the backing array of a buffer.

Patch: Andy Schlaikjer

bryanduxbury : http://svn.apache.org/viewvc/?view=rev&rev=1166292
Files : 
* /thrift/trunk/lib/java/src/org/apache/thrift/TBaseHelper.java
* /thrift/trunk/lib/java/test/org/apache/thrift/TestTBaseHelper.java


> TBaseHelper.toString(...) appends ByteBuffer data outside of valid buffer 
> range
> ---
>
> Key: THRIFT-1328
> URL: https://issues.apache.org/jira/browse/THRIFT-1328
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.5
> Environment: Java 1.6, Mac OSX 10.6.8 64-bit
>Reporter: Andy Schlaikjer
>Assignee: Andy Schlaikjer
> Fix For: 0.8
>
> Attachments: fix-bytebuffer-access-02.patch, 
> fix-bytebuffer-access.patch
>
>
> I have a Thrift struct T which declares a binary field f3 after two other 
> fields f1 and f2. After successful deserialization of a T instance, f3 
> references a ByteBuffer which wraps the raw byte[] containing all T instance 
> data and has position and limit set to scope reads to valid f3 bytes. This is 
> great because it means less copying of raw byte[] data.
> However, TBaseHelper.toString(ByteBuffer bb, StringBuilder sb) uses 
> Buffer.array() and Buffer.arrayOffset() to read f3 data, causing it to append 
> bytes to sb which lie outside f3's valid range in the backing byte[].
> It seems like this logic is also present in latest version of TBaseHelper: 
> http://svn.apache.org/viewvc/thrift/trunk/lib/java/src/org/apache/thrift/TBaseHelper.java?revision=1038833&view=markup#l223

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (THRIFT-1328) TBaseHelper.toString(...) appends ByteBuffer data outside of valid buffer range

2011-09-07 Thread Bryan Duxbury (JIRA) 

 [ 
https://issues.apache.org/jira/browse/THRIFT-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Duxbury closed THRIFT-1328.
-

   Resolution: Fixed
Fix Version/s: 0.8
 Assignee: Andy Schlaikjer

Awesome, this is perfect. Thanks for the prompt revision (and for including 
unit tests)!

> TBaseHelper.toString(...) appends ByteBuffer data outside of valid buffer 
> range
> ---
>
> Key: THRIFT-1328
> URL: https://issues.apache.org/jira/browse/THRIFT-1328
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.5
> Environment: Java 1.6, Mac OSX 10.6.8 64-bit
>Reporter: Andy Schlaikjer
>Assignee: Andy Schlaikjer
> Fix For: 0.8
>
> Attachments: fix-bytebuffer-access-02.patch, 
> fix-bytebuffer-access.patch
>
>
> I have a Thrift struct T which declares a binary field f3 after two other 
> fields f1 and f2. After successful deserialization of a T instance, f3 
> references a ByteBuffer which wraps the raw byte[] containing all T instance 
> data and has position and limit set to scope reads to valid f3 bytes. This is 
> great because it means less copying of raw byte[] data.
> However, TBaseHelper.toString(ByteBuffer bb, StringBuilder sb) uses 
> Buffer.array() and Buffer.arrayOffset() to read f3 data, causing it to append 
> bytes to sb which lie outside f3's valid range in the backing byte[].
> It seems like this logic is also present in latest version of TBaseHelper: 
> http://svn.apache.org/viewvc/thrift/trunk/lib/java/src/org/apache/thrift/TBaseHelper.java?revision=1038833&view=markup#l223

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1328) TBaseHelper.toString(...) appends ByteBuffer data outside of valid buffer range

2011-09-07 Thread Andy Schlaikjer (JIRA) 

[ 
https://issues.apache.org/jira/browse/THRIFT-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099158#comment-13099158
 ] 

Andy Schlaikjer commented on THRIFT-1328:
-

Bryan, please see second attached patch for proper arrayOffset handling. Thanks 
for your correction!

> TBaseHelper.toString(...) appends ByteBuffer data outside of valid buffer 
> range
> ---
>
> Key: THRIFT-1328
> URL: https://issues.apache.org/jira/browse/THRIFT-1328
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.5
> Environment: Java 1.6, Mac OSX 10.6.8 64-bit
>Reporter: Andy Schlaikjer
> Attachments: fix-bytebuffer-access-02.patch, 
> fix-bytebuffer-access.patch
>
>
> I have a Thrift struct T which declares a binary field f3 after two other 
> fields f1 and f2. After successful deserialization of a T instance, f3 
> references a ByteBuffer which wraps the raw byte[] containing all T instance 
> data and has position and limit set to scope reads to valid f3 bytes. This is 
> great because it means less copying of raw byte[] data.
> However, TBaseHelper.toString(ByteBuffer bb, StringBuilder sb) uses 
> Buffer.array() and Buffer.arrayOffset() to read f3 data, causing it to append 
> bytes to sb which lie outside f3's valid range in the backing byte[].
> It seems like this logic is also present in latest version of TBaseHelper: 
> http://svn.apache.org/viewvc/thrift/trunk/lib/java/src/org/apache/thrift/TBaseHelper.java?revision=1038833&view=markup#l223

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1328) TBaseHelper.toString(...) appends ByteBuffer data outside of valid buffer range

2011-09-07 Thread Andy Schlaikjer (JIRA) 

 [ 
https://issues.apache.org/jira/browse/THRIFT-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schlaikjer updated THRIFT-1328:


Attachment: fix-bytebuffer-access-02.patch

> TBaseHelper.toString(...) appends ByteBuffer data outside of valid buffer 
> range
> ---
>
> Key: THRIFT-1328
> URL: https://issues.apache.org/jira/browse/THRIFT-1328
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.5
> Environment: Java 1.6, Mac OSX 10.6.8 64-bit
>Reporter: Andy Schlaikjer
> Attachments: fix-bytebuffer-access-02.patch, 
> fix-bytebuffer-access.patch
>
>
> I have a Thrift struct T which declares a binary field f3 after two other 
> fields f1 and f2. After successful deserialization of a T instance, f3 
> references a ByteBuffer which wraps the raw byte[] containing all T instance 
> data and has position and limit set to scope reads to valid f3 bytes. This is 
> great because it means less copying of raw byte[] data.
> However, TBaseHelper.toString(ByteBuffer bb, StringBuilder sb) uses 
> Buffer.array() and Buffer.arrayOffset() to read f3 data, causing it to append 
> bytes to sb which lie outside f3's valid range in the backing byte[].
> It seems like this logic is also present in latest version of TBaseHelper: 
> http://svn.apache.org/viewvc/thrift/trunk/lib/java/src/org/apache/thrift/TBaseHelper.java?revision=1038833&view=markup#l223

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (THRIFT-1329) is there any plan to enhance TProcessorFactory so that I can identify different request for different TProcessor?!

2011-09-07 Thread Bryan Duxbury (JIRA) 

 [ 
https://issues.apache.org/jira/browse/THRIFT-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Duxbury closed THRIFT-1329.
-

Resolution: Invalid

We don't currently have any plans to implement a feature like this. You are 
already free to create new TProcessorFactory implementations that can do more 
complicated things, though as you point out, we may not be giving you enough 
information to do what you'd like. 

However, generally speaking, Thrift doesn't want to serve more than one service 
over a single port. You're on your own to figure that out or propose features 
that would make it easy to do.

Also, this kind of question is better asked on the mailing list than in a JIRA 
ticket, so I'm closing it. If you would like to convert the content of this 
ticket into a more concise feature request, that would be OK too.

> is there any plan to enhance TProcessorFactory so that I can identify 
> different request for different TProcessor?!
> --
>
> Key: THRIFT-1329
> URL: https://issues.apache.org/jira/browse/THRIFT-1329
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Affects Versions: 0.7
>Reporter: darren wang
>
> Here is what I want: (maybe I am using thrift in some improper way, if so, 
> please point me out)
> In most of the sample applications I found from internet, they just expose 
> one service via one TServer, that's ok for just one, but I want to expose 
> multiple service via one TServer, I don't know whether thrift has some 
> support for this situation, since I just get to know thrift in 1-2 days, so I 
> tries to read the code to find out how to achieve it.
> What I found is almost each TServer impl. will retrieve a TProcessor instance 
> to handle the request by getting the processor instance from default 
> TProcessorFactory as per current TTransport instance. But since default 
> TProcessorFactory just return same singleton instance each time, the reason 
> to lookup different TProcessor as per current TTransport is weak. I can't 
> find any useful information from the TTransport to help to identify which one 
> processor to use for current transport. 
> What I am wondering is, will u enhance the TProcessorFactory via passing in 
> more information to help to identify different processors to use? or will u 
> enhance some other facilities in the library? or some other way I can resort 
> to?
> Thanks

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1328) TBaseHelper.toString(...) appends ByteBuffer data outside of valid buffer range

2011-09-07 Thread Bryan Duxbury (JIRA) 

[ 
https://issues.apache.org/jira/browse/THRIFT-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099143#comment-13099143
 ] 

Bryan Duxbury commented on THRIFT-1328:
---

Good catch, Andy. However, your fix has a hole in it. If the ByteBuffer has a 
nonzero arrayOffset (as it would after, say, a slice() call), then you'll be 
reading from before the beginning of the buffer. All we need to do is offset 
all the indices by arrayOffset() and we should be fine. Do you want to take a 
crack at another version?

> TBaseHelper.toString(...) appends ByteBuffer data outside of valid buffer 
> range
> ---
>
> Key: THRIFT-1328
> URL: https://issues.apache.org/jira/browse/THRIFT-1328
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.5
> Environment: Java 1.6, Mac OSX 10.6.8 64-bit
>Reporter: Andy Schlaikjer
> Attachments: fix-bytebuffer-access.patch
>
>
> I have a Thrift struct T which declares a binary field f3 after two other 
> fields f1 and f2. After successful deserialization of a T instance, f3 
> references a ByteBuffer which wraps the raw byte[] containing all T instance 
> data and has position and limit set to scope reads to valid f3 bytes. This is 
> great because it means less copying of raw byte[] data.
> However, TBaseHelper.toString(ByteBuffer bb, StringBuilder sb) uses 
> Buffer.array() and Buffer.arrayOffset() to read f3 data, causing it to append 
> bytes to sb which lie outside f3's valid range in the backing byte[].
> It seems like this logic is also present in latest version of TBaseHelper: 
> http://svn.apache.org/viewvc/thrift/trunk/lib/java/src/org/apache/thrift/TBaseHelper.java?revision=1038833&view=markup#l223

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1330) PHP Namespaces no longer generated

2011-09-07 Thread B Armstrong (JIRA) 

 [ 
https://issues.apache.org/jira/browse/THRIFT-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

B Armstrong updated THRIFT-1330:


Comment: was deleted

(was: It should be noted that this bug is reporting that the "compatibility 
with older version of php" has been broken.)

> PHP Namespaces no longer generated
> --
>
> Key: THRIFT-1330
> URL: https://issues.apache.org/jira/browse/THRIFT-1330
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Compiler
>Affects Versions: 0.7, 0.8
> Environment: Mac OS X 10.6.8, CentOS 5.6, Ubuntu 11.04
>Reporter: B Armstrong
>Assignee: Jake Farrell
>Priority: Critical
>
> PHP namespaces are not being generated, ever. PHP 5.3 namespace aren't 
> generated either.
> The following will illustrate the bug. This works in Thrift 0.6.*
> $ thrift -version
> Thrift version 0.7.0
> $ cat > test.thrift
> namespace php TestNamespace
> struct ItemX {}
> $ thrift --gen php test.thrift
> $ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
> echo "NO NAMESPACE FOUND"
> NO NAMESPACE FOUND
> $ thrift -version
> Thrift version 0.8.0-dev
> $ thrift -gen php test.thrift 
> $ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
> echo "NO NAMESPACE FOUND"
> NO NAMESPACE FOUND

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1330) PHP Namespaces no longer generated

2011-09-07 Thread B Armstrong (JIRA) 

[ 
https://issues.apache.org/jira/browse/THRIFT-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099134#comment-13099134
 ] 

B Armstrong commented on THRIFT-1330:
-

It should be noted that this bug is reporting that the "compatibility with 
older versions of php" has been broken.

> PHP Namespaces no longer generated
> --
>
> Key: THRIFT-1330
> URL: https://issues.apache.org/jira/browse/THRIFT-1330
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Compiler
>Affects Versions: 0.7, 0.8
> Environment: Mac OS X 10.6.8, CentOS 5.6, Ubuntu 11.04
>Reporter: B Armstrong
>Assignee: Jake Farrell
>Priority: Critical
>
> PHP namespaces are not being generated, ever. PHP 5.3 namespace aren't 
> generated either.
> The following will illustrate the bug. This works in Thrift 0.6.*
> $ thrift -version
> Thrift version 0.7.0
> $ cat > test.thrift
> namespace php TestNamespace
> struct ItemX {}
> $ thrift --gen php test.thrift
> $ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
> echo "NO NAMESPACE FOUND"
> NO NAMESPACE FOUND
> $ thrift -version
> Thrift version 0.8.0-dev
> $ thrift -gen php test.thrift 
> $ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
> echo "NO NAMESPACE FOUND"
> NO NAMESPACE FOUND

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1331) Ruby library deserializes an empty map to nil

2011-09-07 Thread Armaan Sarkar (JIRA) 

 [ 
https://issues.apache.org/jira/browse/THRIFT-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Armaan Sarkar updated THRIFT-1331:
--

Attachment: THRIFT-1331_v1.patch

This patch adds an empty check when deserializing maps (in both Ruby and the C 
extension). It also includes an additional spec for this case.

> Ruby library deserializes an empty map to nil
> -
>
> Key: THRIFT-1331
> URL: https://issues.apache.org/jira/browse/THRIFT-1331
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.7, 0.8
>Reporter: Armaan Sarkar
>Assignee: Armaan Sarkar
> Attachments: THRIFT-1331_v1.patch
>
>
> The problem occurs when deserializing an empty map. Instead of deserializing 
> to an empty hash in Ruby, Thrift currently makes it a nil object. This poses 
> a variety of problems and is not the intended/original behavior. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1330) PHP Namespaces no longer generated

2011-09-07 Thread B Armstrong (JIRA) 

[ 
https://issues.apache.org/jira/browse/THRIFT-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099127#comment-13099127
 ] 

B Armstrong commented on THRIFT-1330:
-

It should be noted that this bug is reporting that the "compatibility with 
older version of php" has been broken.

> PHP Namespaces no longer generated
> --
>
> Key: THRIFT-1330
> URL: https://issues.apache.org/jira/browse/THRIFT-1330
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Compiler
>Affects Versions: 0.7, 0.8
> Environment: Mac OS X 10.6.8, CentOS 5.6, Ubuntu 11.04
>Reporter: B Armstrong
>Assignee: Jake Farrell
>Priority: Critical
>
> PHP namespaces are not being generated, ever. PHP 5.3 namespace aren't 
> generated either.
> The following will illustrate the bug. This works in Thrift 0.6.*
> $ thrift -version
> Thrift version 0.7.0
> $ cat > test.thrift
> namespace php TestNamespace
> struct ItemX {}
> $ thrift --gen php test.thrift
> $ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
> echo "NO NAMESPACE FOUND"
> NO NAMESPACE FOUND
> $ thrift -version
> Thrift version 0.8.0-dev
> $ thrift -gen php test.thrift 
> $ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
> echo "NO NAMESPACE FOUND"
> NO NAMESPACE FOUND

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (THRIFT-1330) PHP Namespaces no longer generated

2011-09-07 Thread B Armstrong (JIRA) 

[ 
https://issues.apache.org/jira/browse/THRIFT-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099122#comment-13099122
 ] 

B Armstrong edited comment on THRIFT-1330 at 9/7/11 5:34 PM:
-

The 'namespace' options adds the PHP 5.3 style namespace, that is correct. I 
guess my bug was poorly written up.

The actual bug is that we can't get the PHP 5.2 style of "namespacing". AKA 
Prefixing all of the classes with the "namespace" name.

Here is the output with thrift 0.6.0:

$ thrift -version
Thrift version 0.6.0
$ thrift -gen php test.thrift 
$ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
echo "NO NAMESPACE FOUND"
class TestNamespace_ItemX {
Has namespace

With thrift 0.7.0 and 0.8.0 we cannot get the old functionality to work.

  was (Author: barmstr...@qualtrics.com):
The 'namespace' options adds the PHP 5.3 style namespace, that is correct. 
I guess my bug was poorly written up.

The actual bug is that we can't get the PHP 5.2 style of "namespacing". AKA 
Prefixing all of the classes with the namespace name.

Here is the output with thrift 0.6.0:

$ thrift -version
Thrift version 0.6.0
$ thrift -gen php test.thrift 
$ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
echo "NO NAMESPACE FOUND"
class TestNamespace_ItemX {
Has namespace

With thrift 0.7.0 and 0.8.0 we cannot get the old functionality to work.
  
> PHP Namespaces no longer generated
> --
>
> Key: THRIFT-1330
> URL: https://issues.apache.org/jira/browse/THRIFT-1330
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Compiler
>Affects Versions: 0.7, 0.8
> Environment: Mac OS X 10.6.8, CentOS 5.6, Ubuntu 11.04
>Reporter: B Armstrong
>Assignee: Jake Farrell
>Priority: Critical
>
> PHP namespaces are not being generated, ever. PHP 5.3 namespace aren't 
> generated either.
> The following will illustrate the bug. This works in Thrift 0.6.*
> $ thrift -version
> Thrift version 0.7.0
> $ cat > test.thrift
> namespace php TestNamespace
> struct ItemX {}
> $ thrift --gen php test.thrift
> $ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
> echo "NO NAMESPACE FOUND"
> NO NAMESPACE FOUND
> $ thrift -version
> Thrift version 0.8.0-dev
> $ thrift -gen php test.thrift 
> $ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
> echo "NO NAMESPACE FOUND"
> NO NAMESPACE FOUND

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (THRIFT-1330) PHP Namespaces no longer generated

2011-09-07 Thread B Armstrong (JIRA) 

 [ 
https://issues.apache.org/jira/browse/THRIFT-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

B Armstrong reopened THRIFT-1330:
-


The 'namespace' options adds the PHP 5.3 style namespace, that is correct. I 
guess my bug was poorly written up.

The actual bug is that we can't get the PHP 5.2 style of "namespacing". AKA 
Prefixing all of the classes with the namespace name.

Here is the output with thrift 0.6.0:

$ thrift -version
Thrift version 0.6.0
$ thrift -gen php test.thrift 
$ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
echo "NO NAMESPACE FOUND"
class TestNamespace_ItemX {
Has namespace

With thrift 0.7.0 and 0.8.0 we cannot get the old functionality to work.

> PHP Namespaces no longer generated
> --
>
> Key: THRIFT-1330
> URL: https://issues.apache.org/jira/browse/THRIFT-1330
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Compiler
>Affects Versions: 0.7, 0.8
> Environment: Mac OS X 10.6.8, CentOS 5.6, Ubuntu 11.04
>Reporter: B Armstrong
>Assignee: Jake Farrell
>Priority: Critical
>
> PHP namespaces are not being generated, ever. PHP 5.3 namespace aren't 
> generated either.
> The following will illustrate the bug. This works in Thrift 0.6.*
> $ thrift -version
> Thrift version 0.7.0
> $ cat > test.thrift
> namespace php TestNamespace
> struct ItemX {}
> $ thrift --gen php test.thrift
> $ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
> echo "NO NAMESPACE FOUND"
> NO NAMESPACE FOUND
> $ thrift -version
> Thrift version 0.8.0-dev
> $ thrift -gen php test.thrift 
> $ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
> echo "NO NAMESPACE FOUND"
> NO NAMESPACE FOUND

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (THRIFT-1331) Ruby library deserializes an empty map to nil

2011-09-07 Thread Armaan Sarkar (JIRA) 
Ruby library deserializes an empty map to nil
-

 Key: THRIFT-1331
 URL: https://issues.apache.org/jira/browse/THRIFT-1331
 Project: Thrift
  Issue Type: Bug
  Components: Ruby - Library
Affects Versions: 0.7, 0.8
Reporter: Armaan Sarkar
Assignee: Armaan Sarkar


The problem occurs when deserializing an empty map. Instead of deserializing to 
an empty hash in Ruby, Thrift currently makes it a nil object. This poses a 
variety of problems and is not the intended/original behavior. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (THRIFT-1330) PHP Namespaces no longer generated

2011-09-07 Thread Jake Farrell (JIRA) 

 [ 
https://issues.apache.org/jira/browse/THRIFT-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jake Farrell closed THRIFT-1330.


Resolution: Not A Problem
  Assignee: Jake Farrell

the compiler was given a 'namespace' option to not break compatibility with 
older versions of php. From thrift --help

namespace:   Generate PHP namespaces as defined in PHP >= 5.3


> thrift --gen php:namespace test.thrift
> grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
> echo "NO NAMESPACE FOUND"
namespace TestNamespace;
Has namespace

> PHP Namespaces no longer generated
> --
>
> Key: THRIFT-1330
> URL: https://issues.apache.org/jira/browse/THRIFT-1330
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Compiler
>Affects Versions: 0.7, 0.8
> Environment: Mac OS X 10.6.8, CentOS 5.6, Ubuntu 11.04
>Reporter: B Armstrong
>Assignee: Jake Farrell
>Priority: Critical
>
> PHP namespaces are not being generated, ever. PHP 5.3 namespace aren't 
> generated either.
> The following will illustrate the bug. This works in Thrift 0.6.*
> $ thrift -version
> Thrift version 0.7.0
> $ cat > test.thrift
> namespace php TestNamespace
> struct ItemX {}
> $ thrift --gen php test.thrift
> $ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
> echo "NO NAMESPACE FOUND"
> NO NAMESPACE FOUND
> $ thrift -version
> Thrift version 0.8.0-dev
> $ thrift -gen php test.thrift 
> $ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
> echo "NO NAMESPACE FOUND"
> NO NAMESPACE FOUND

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1330) PHP Namespaces no longer generated

2011-09-07 Thread B Armstrong (JIRA) 

 [ 
https://issues.apache.org/jira/browse/THRIFT-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

B Armstrong updated THRIFT-1330:


  Description: 
PHP namespaces are not being generated, ever. PHP 5.3 namespace aren't 
generated either.

The following will illustrate the bug. This works in Thrift 0.6.*

$ thrift -version
Thrift version 0.7.0
$ cat > test.thrift
namespace php TestNamespace
struct ItemX {}
$ thrift --gen php test.thrift
$ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
echo "NO NAMESPACE FOUND"
NO NAMESPACE FOUND

$ thrift -version
Thrift version 0.8.0-dev
$ thrift -gen php test.thrift 
$ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
echo "NO NAMESPACE FOUND"
NO NAMESPACE FOUND

  was:
PHP namespaces are not being generated, ever. PHP 5.3 namespace aren't 
generated either.

The following will illustrate the bug. This works in Thrift 0.6.*

$ thrift -version
Thrift version 0.7.0
$ cat > test.thrift
namespace php TestNamespace
struct ItemX {}
$ thrift --gen php test.thrift
$ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
echo "NO NAMESPACE FOUND"
NO NAMESPACE FOUND

Affects Version/s: 0.8

> PHP Namespaces no longer generated
> --
>
> Key: THRIFT-1330
> URL: https://issues.apache.org/jira/browse/THRIFT-1330
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Compiler
>Affects Versions: 0.7, 0.8
> Environment: Mac OS X 10.6.8, CentOS 5.6, Ubuntu 11.04
>Reporter: B Armstrong
>Priority: Critical
>
> PHP namespaces are not being generated, ever. PHP 5.3 namespace aren't 
> generated either.
> The following will illustrate the bug. This works in Thrift 0.6.*
> $ thrift -version
> Thrift version 0.7.0
> $ cat > test.thrift
> namespace php TestNamespace
> struct ItemX {}
> $ thrift --gen php test.thrift
> $ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
> echo "NO NAMESPACE FOUND"
> NO NAMESPACE FOUND
> $ thrift -version
> Thrift version 0.8.0-dev
> $ thrift -gen php test.thrift 
> $ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
> echo "NO NAMESPACE FOUND"
> NO NAMESPACE FOUND

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (THRIFT-1330) PHP Namespaces no longer generated

2011-09-07 Thread B Armstrong (JIRA) 
PHP Namespaces no longer generated
--

 Key: THRIFT-1330
 URL: https://issues.apache.org/jira/browse/THRIFT-1330
 Project: Thrift
  Issue Type: Bug
  Components: PHP - Compiler
Affects Versions: 0.7
 Environment: Mac OS X 10.6.8, CentOS 5.6, Ubuntu 11.04
Reporter: B Armstrong
Priority: Critical


PHP namespaces are not being generated, ever. PHP 5.3 namespace aren't 
generated either.

The following will illustrate the bug. This works in Thrift 0.6.*

$ thrift -version
Thrift version 0.7.0
$ cat > test.thrift
namespace php TestNamespace
struct ItemX {}
$ thrift --gen php test.thrift
$ grep "TestNamespace" gen-php/test/test_types.php && echo "Has namespace" || 
echo "NO NAMESPACE FOUND"
NO NAMESPACE FOUND

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1267) Node.js can't throw exceptions.

2011-09-07 Thread Hans Duedal (JIRA) 

 [ 
https://issues.apache.org/jira/browse/THRIFT-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hans Duedal updated THRIFT-1267:


Attachment: thrift-1267-callback-ns-fix.patch

New version. The previous one didn't get the namespace right for exceptions 
that where included from other files.

> Node.js can't throw exceptions. 
> 
>
> Key: THRIFT-1267
> URL: https://issues.apache.org/jira/browse/THRIFT-1267
> Project: Thrift
>  Issue Type: Improvement
>  Components: JavaScript - Compiler
>Affects Versions: 0.7
>Reporter: Hans Duedal
>  Labels: compiler, javascript, node, nodejs
> Fix For: 0.8
>
> Attachments: nodejs-exception.patch, 
> thrift-1267-callback-ns-fix.patch, thrift-1267-callback.patch
>
>
> There is no way as far as I can tell for node.js servers to throw thrift 
> exceptions.
> I have made a patch to allow it to throw exceptions. It lets the node.js 
> server implementation give params directly to the result object, thereby 
> being able to specify the exception. It doesn't affect normal (non exception) 
> return data.
> Test case: https://gist.github.com/1151782
> Install thrift module "npm install thrift", generate thrift "thrift --gen 
> js:node test.thrift" and run server then client.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (THRIFT-1329) is there any plan to enhance TProcessorFactory so that I can identify different request for different TProcessor?!

2011-09-07 Thread darren wang (JIRA) 
is there any plan to enhance TProcessorFactory so that I can identify different 
request for different TProcessor?!
--

 Key: THRIFT-1329
 URL: https://issues.apache.org/jira/browse/THRIFT-1329
 Project: Thrift
  Issue Type: Improvement
  Components: Java - Library
Affects Versions: 0.7
Reporter: darren wang


Here is what I want: (maybe I am using thrift in some improper way, if so, 
please point me out)

In most of the sample applications I found from internet, they just expose one 
service via one TServer, that's ok for just one, but I want to expose multiple 
service via one TServer, I don't know whether thrift has some support for this 
situation, since I just get to know thrift in 1-2 days, so I tries to read the 
code to find out how to achieve it.

What I found is almost each TServer impl. will retrieve a TProcessor instance 
to handle the request by getting the processor instance from default 
TProcessorFactory as per current TTransport instance. But since default 
TProcessorFactory just return same singleton instance each time, the reason to 
lookup different TProcessor as per current TTransport is weak. I can't find any 
useful information from the TTransport to help to identify which one processor 
to use for current transport. 

What I am wondering is, will u enhance the TProcessorFactory via passing in 
more information to help to identify different processors to use? or will u 
enhance some other facilities in the library? or some other way I can resort to?

Thanks


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1325) Thrift SVN and latest GCC issue: Undefined symbols: "apache::thrift::protocol::TBinaryProtocolT::VERSION_MASK"

2011-09-07 Thread Matthieu Imbert (JIRA) 

[ 
https://issues.apache.org/jira/browse/THRIFT-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098665#comment-13098665
 ] 

Matthieu Imbert commented on THRIFT-1325:
-

i had the same issue on debian linux, also with gcc 4.6.1.
i think this is a bug in gcc. I filled a bug to gcc here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49896
for example, gcc 4.6 does not like:

static const int32_t VERSION_1 = 0x8001;

because 0x8001 is an unsigned int 32 literal.

one solution might be to replace in thrift includes the version
constants with the same constant already converted to a signed
literal:

in TBinaryProtocol.h, replace:
  
- static const int32_t VERSION_MASK = 0x;

  by

  static const int32_t VERSION_MASK = -0x0001;

- static const int32_t VERSION_1 = 0x8001;

  by

  static const int32_t VERSION_1 = -0x7fff;

in TDenseProtocol.h, replace:

- static const int32_t VERSION_2 = 0x8002;

  by static const int32_t VERSION_2 = -0x7ffe;

i haven't tested it though.


> Thrift SVN and latest GCC issue: Undefined symbols: 
> "apache::thrift::protocol::TBinaryProtocolT::VERSION_MASK"
> -
>
> Key: THRIFT-1325
> URL: https://issues.apache.org/jira/browse/THRIFT-1325
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
> Environment: Mac OS 10.6.8 x86_64, GNU GCC 4.6.1 hand compiled
>Reporter: Philippe STRAUSS
>Priority: Blocker
> Fix For: 0.8
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I need latest gcc for a pet project of mine using intrisics. Using GCC 4.6.1, 
> building code generated by thrift for a C++ server, I always get the error 
> cut and pasted below at link time. Using apple shipped gcc 4.2.1 it build 
> (link) fine, but cannot use it for another part of my project :(
> + /opt/gnucc/bin/g++ -g -DDEBUG -I/usr/local/include -I/opt/local/include 
> -I/opt/misc/include -I/opt/misc/include/thrift -I/opt/av/include 
> -I/opt/num/include -o jack_preamp.nat jack_preamp.o rc_types.o rc_constants.o 
> Control.o ../common_c/libcommon.a ../jackc/libjackc.a ../config/libcf.a 
> ../libsigpath/libsigpath.a -framework CoreAudio -framework CoreServices 
> -framework AudioUnit -L/usr/local/lib -ljack -L/opt/local/lib -lsndfile 
> -L/opt/misc/lib -lconfig -L/opt/misc/lib -lthrift -L/opt/av/lib 
> -L/opt/num/lib -lconvolve -lsndfile -lsamplerate -lfftw3f
> Undefined symbols:
>   
> "apache::thrift::protocol::TBinaryProtocolT::VERSION_MASK",
>  [==referenced 
> from:==  ] 
> 00225 / 00227
>   
> apache::thrift::protocol::TBinaryProtocolT::readMessageBegin(std::basic_string  std::char_traits, std::allocator >&, 
> apache::thrift::protocol::TMessageType&, int&) in jack_preamp.o
>   
> "apache::thrift::protocol::TBinaryProtocolT::VERSION_1",
>  referenced from:
>   
> apache::thrift::protocol::TBinaryProtocolT::writeMessageBegin(std::basic_string  std::char_traits, std::allocator > const&, 
> apache::thrift::protocol::TMessageType, int) in jack_preamp.o
>   
> apache::thrift::protocol::TBinaryProtocolT::readMessageBegin(std::basic_string  std::char_traits, std::allocator >&, 
> apache::thrift::protocol::TMessageType&, int&) in jack_preamp.o
> ld: symbol(s) not found
> collect2: ld a retourné 1 code d'état d'exécution

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira