You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Aleksandrs Saveljevs (JIRA)" <ji...@apache.org> on 2012/06/11 06:30:43 UTC

[jira] [Updated] (THRIFT-1266) generated C code for iterating over nested maps is wrong

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

Aleksandrs Saveljevs updated THRIFT-1266:
-----------------------------------------

    Description: 
We are working with Cassandra API in C generated by Thrift and have noticed a bug in the generated code for cassandra_client_send_batch_mutate().

Full code that Thrift generates for this function is attached, but here is the specification for Cassandra's batch_mutate method:

{code}/**
  Mutate many columns or super columns for many row keys. See also: Mutation.

  mutation_map maps key to column family to a list of Mutation objects to take place at that scope.
**/
void batch_mutate(1:required map<binary, map<string, list<Mutation>>> mutation_map,
                  2:required ConsistencyLevel consistency_level=ConsistencyLevel.ONE)
     throws (1:InvalidRequestException ire, 2:UnavailableException ue, 3:TimedOutException te),
{code}

If we now look at the generated code, we will notice the following fragment:

{code}GPtrArray * value;
g_hash_table_foreach ((GHashTable *)  value, thrift_hash_table_get_keys, &key_list); /* LINE A */
{code}

We can see that in line A it uses the variable "value" as GHashTable, even though the GHashTable "value" was shadowed by GPtrArray "value" a line before.

Similarly, we can see another fragment below that one, where one instance of variable "value" shadows another instance:

{code}
value = (GPtrArray *) g_hash_table_lookup (((GHashTable *)  value), (gpointer) key); /* LINE B */
{code}

We have worked around the bug in our particular case by renaming one of the "value" variables to "value2" (see "svn di -c 21176 svn://svn.zabbix.com/branches/dev/ZBXNEXT-844/src/libs/zbxcassa/cassandra.c@21176" for a diff), but it would be nice to fix it in Thrift, too.

  was:
We are working with Cassandra API in C generated by Thrift and have noticed a bug in the generated code for cassandra_client_send_batch_mutate().

Full code that Thrift generates for this function is attached, but here is the specification for Cassandra's batch_mutate method:

{code}/**
  Mutate many columns or super columns for many row keys. See also: Mutation.

  mutation_map maps key to column family to a list of Mutation objects to take place at that scope.
**/
void batch_mutate(1:required map<binary, map<string, list<Mutation>>> mutation_map,
                  2:required ConsistencyLevel consistency_level=ConsistencyLevel.ONE)
     throws (1:InvalidRequestException ire, 2:UnavailableException ue, 3:TimedOutException te),
{code}

If we now look at the generated code, we will notice the following fragment:

{code}GPtrArray * value;
g_hash_table_foreach ((GHashTable *)  value, thrift_hash_table_get_keys, &key_list); /* LINE A */
{code}

We can see that in line A it uses the variable "value" as GHashTable, even though the GHashTable "value" was shadowed by GPtrArray "value" a line before.

Similarly, we can see another fragment below that one, where one instance of variable "value" shadows another instance:

{code}
value = (GPtrArray *) g_hash_table_lookup (((GHashTable *)  value), (gpointer) key); /* LINE B */
{code}

We have worked around the bug in our particular case by renaming one of the "value" variables to "value2" (see "svn di -c 21176 svn://svn.zabbix.com/branches/dev/ZBXNEXT-844/src/libs/zbxcassa/cassandra.c" for a diff), but it would be nice to fix it in Thrift, too.

    
> generated C code for iterating over nested maps is wrong
> --------------------------------------------------------
>
>                 Key: THRIFT-1266
>                 URL: https://issues.apache.org/jira/browse/THRIFT-1266
>             Project: Thrift
>          Issue Type: Bug
>          Components: C glib - Compiler
>    Affects Versions: 0.8
>         Environment: Revision 1158683 of http://svn.apache.org/repos/asf/thrift/trunk.
>            Reporter: Aleksandrs Saveljevs
>            Priority: Critical
>              Labels: c_glib, cassandra
>         Attachments: batch_mutate.c
>
>
> We are working with Cassandra API in C generated by Thrift and have noticed a bug in the generated code for cassandra_client_send_batch_mutate().
> Full code that Thrift generates for this function is attached, but here is the specification for Cassandra's batch_mutate method:
> {code}/**
>   Mutate many columns or super columns for many row keys. See also: Mutation.
>   mutation_map maps key to column family to a list of Mutation objects to take place at that scope.
> **/
> void batch_mutate(1:required map<binary, map<string, list<Mutation>>> mutation_map,
>                   2:required ConsistencyLevel consistency_level=ConsistencyLevel.ONE)
>      throws (1:InvalidRequestException ire, 2:UnavailableException ue, 3:TimedOutException te),
> {code}
> If we now look at the generated code, we will notice the following fragment:
> {code}GPtrArray * value;
> g_hash_table_foreach ((GHashTable *)  value, thrift_hash_table_get_keys, &key_list); /* LINE A */
> {code}
> We can see that in line A it uses the variable "value" as GHashTable, even though the GHashTable "value" was shadowed by GPtrArray "value" a line before.
> Similarly, we can see another fragment below that one, where one instance of variable "value" shadows another instance:
> {code}
> value = (GPtrArray *) g_hash_table_lookup (((GHashTable *)  value), (gpointer) key); /* LINE B */
> {code}
> We have worked around the bug in our particular case by renaming one of the "value" variables to "value2" (see "svn di -c 21176 svn://svn.zabbix.com/branches/dev/ZBXNEXT-844/src/libs/zbxcassa/cassandra.c@21176" for a diff), but it would be nice to fix it in Thrift, too.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira