I am currently working with Eclipse CDT, the ESP-IDF framework and the ESP32 Wrover DevKit .
I was looking for a C
vector implementation and stumbled over rxi/vec on GitHub . I copied vec.h
and vec.c
to my project and tried to compile. I am getting the following error:
Error: right-hand operand of comma expression has no effect[-Werror=unused-value]
... at this line of code in vec.h
:
#define vec_push(v, val)\
( vec_expand_(vec_unpack_(v)) ? -1 :\
((v)->data[(v)->length++] = (val), 0), 0 )
Any ideas how solve this issue or work around? Any alternative vector implementation for C
?
../main/tools/inc/vec.h:35:42: error: right-hand operand of comma expression has no effect [-Werror=unused-value]
( vec_expand_(vec_unpack_(v)) ? -1 :\
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
((v)->data[(v)->length++] = (val), 0), 0 )
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
../main/main.c:44:2: note: in expansion of macro 'vec_push'
vec_push(&toc.items, item1);
^~~~~~~~
../main/tools/inc/vec.h:35:42: error: right-hand operand of comma expression has no effect [-Werror=unused-value]
( vec_expand_(vec_unpack_(v)) ? -1 :\
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
((v)->data[(v)->length++] = (val), 0), 0 )
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
../main/main.c:50:2: note: in expansion of macro 'vec_push'
vec_push(&item1.elements, elem1);
^~~~~~~~
../main/tools/inc/vec.h:35:42: error: right-hand operand of comma expression has no effect [-Werror=unused-value]
( vec_expand_(vec_unpack_(v)) ? -1 :\
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
((v)->data[(v)->length++] = (val), 0), 0 )
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
../main/main.c:56:2: note: in expansion of macro 'vec_push'
vec_push(&item1.elements, elem2);
^~~~~~~~
cc1: some warnings being treated as errors
#include <stdio.h>
#include <stdlib.h>
#include "vec.h"
typedef struct toc_element_t {
uint16_t uid;
char element[8];
char type[8];
} toc_element_t;
typedef vec_t(toc_element_t) vec_toc_element_t;
typedef struct toc_item_t {
char category[8];
vec_toc_element_t elements;
} toc_item_t;
typedef vec_t(toc_item_t) vec_toc_item_t;
typedef struct toc_t {
char description[8];
vec_toc_item_t items;
} toc_t;
void app_main(void) {
toc_t toc;
strcpy(toc.description, "toc1");
vec_init(&toc.items);
toc_item_t item1;
strcpy(item1.category, "cat1");
vec_init(&item1.elements);
vec_push(&toc.items, item1);
toc_element_t elem1;
elem1.uid=0;
strcpy(elem1.element, "elem1");
strcpy(elem1.type, "float");
vec_push(&item1.elements, elem1);
toc_element_t elem2;
elem2.uid=1;
strcpy(elem2.element, "elem2");
strcpy(elem2.type, "float");
vec_push(&item1.elements, elem2);
printf("TOC [%s]:\n", toc.description);
toc_item_t item; int index1;
vec_foreach(&toc.items, item, index1) {
printf(" - item[%d]=%s\n", index1, item.category);
toc_element_t element; int index2;
vec_foreach(&item.elements, element, index2) {
printf(" - element[%d]=%s [%s]\n", index2, element.element, element.type);
}
}
while(1);
}
Perhaps this issue is not related to this question, but since Eric mentioned the last commit with the log message “Fixed vec_insert() and vec_push() for structs” that inserted the 'fishy' ,0
that caused the problem discussed here, it may nonetheless be related.
When executing the code in section "Update B", I get the following output:
TOC [toc1]:
- item[0]=cat1
But I would expect the following:
TOC [toc1]:
- item[0]=cat1
- element[0]=elem1
- element[1]=elem2
The compiler is right to warn you. Something is fishy there. The … ? -1 : (…, 0)
… ? -1 : (…, 0)
part is designed to return a success/failure indication, and then the trailing , 0
throws that away. It is “valid code” in that it does not violate a rule of the C standard, but there is clearly a design or coding error there.
The extra , 0
was introduced in commit dd55e00e17d454f54b905fdcf6718ba0c1ed94b0, with the log message “Fixed vec_insert() and vec_push() for structs”. It and the same change to vec_insert
are the only changes in that commit:
--- a/src/vec.h
+++ b/src/vec.h
@@ -33,7 +33,7 @@
#define vec_push(v, val)\
( vec_expand_(vec_unpack_(v)) ? -1 :\
- ((v)->data[(v)->length++] = (val)), 0 )
+ ((v)->data[(v)->length++] = (val), 0), 0 )
#define vec_pop(v)\
@@ -52,7 +52,7 @@
#define vec_insert(v, idx, val)\
( vec_insert_(vec_unpack_(v), idx) ? -1 :\
- ((v)->data[idx] = (val)), (v)->length++, 0 )
+ ((v)->data[idx] = (val), 0), (v)->length++, 0 )
I do not see how those changes comport with the log message. I think it is a mistake. Note that the pre-commit code was wrong; this code:
( vec_expand_(vec_unpack_(v)) ? -1 :\
((v)->data[(v)->length++] = (val)), 0 )
has the pattern (Test ? -1 : (Operation), 0)
. That always produces 0, since the comma operator is the lowest precedence. The commit changes it to (Test ? -1 : (Operation, 0), 0)
, which has equivalent behavior—on the :
side, the operation is performed, but then the result is discarded, 0 is evaluated and discarded, and then there is another 0. If the commit had changed it to (Test ? -1 : (Operation, 0))
, that would make sense. The commit would be fixing an error, in that the macro previously always produced 0 but would now produce 0 or −1 according to whether the operation was successful or not.
None of the tests in the repository check the “return” value of vec_push
.
It should be safe to remove the , 0
. The resulting expansion will continue to evaluate to zero in normal situations. It will change to evaluate to −1 if the push fails (because memory allocation fails), but that would seem to be desirable. Good code should be:
#define vec_push(v, val)\
( vec_expand_(vec_unpack_(v)) ? -1 :\
((v)->data[(v)->length++] = (val), 0))
Also make the same change to vec_insert
and look for any similar code that needs to be fixed.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.