[PATCH 5/6] ncmul::eval(): don't write beyond the end of the vector.

[Alexei Sheplyakov-3]

---
 ginac/ncmul.cpp |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/ginac/ncmul.cpp b/ginac/ncmul.cpp
index 0c22a81..fff307d 100644
--- a/ginac/ncmul.cpp
+++ b/ginac/ncmul.cpp
@@ -339,15 +339,15 @@ ex ncmul::eval(int level) const
  if (assocseq.empty()) return _ex1;
 
  // determine return types
- unsignedvector rettypes;
- rettypes.reserve(assocseq.size());
+ unsignedvector rettypes(assocseq.size());
  size_t i = 0;
  size_t count_commutative=0;
  size_t count_noncommutative=0;
  size_t count_noncommutative_composite=0;
  cit = assocseq.begin(); citend = assocseq.end();
  while (cit != citend) {
- switch (rettypes[i] = cit->return_type()) {
+ rettypes[i] = cit->return_type();
+ switch (rettypes[i]) {
  case return_types::commutative:
  count_commutative++;
  break;
--
1.6.3.3

_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

[Jens Vollinga]

Hi Alexei,

I don't quite understand this patch (at least not in connection to its
description). Yes, it improves the allocation, and then it does
something that looks as if someone prefers to program in Python ...
Is this the intent and the message is just wrong?

Regards,
Jens


Alexei Sheplyakov schrieb:

> ---
>  ginac/ncmul.cpp |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/ginac/ncmul.cpp b/ginac/ncmul.cpp
> index 0c22a81..fff307d 100644
> --- a/ginac/ncmul.cpp
> +++ b/ginac/ncmul.cpp
> @@ -339,15 +339,15 @@ ex ncmul::eval(int level) const
>   if (assocseq.empty()) return _ex1;
>  
>   // determine return types
> - unsignedvector rettypes;
> - rettypes.reserve(assocseq.size());
> + unsignedvector rettypes(assocseq.size());
>   size_t i = 0;
>   size_t count_commutative=0;
>   size_t count_noncommutative=0;
>   size_t count_noncommutative_composite=0;
>   cit = assocseq.begin(); citend = assocseq.end();
>   while (cit != citend) {
> - switch (rettypes[i] = cit->return_type()) {
> + rettypes[i] = cit->return_type();
> + switch (rettypes[i]) {
>   case return_types::commutative:
>   count_commutative++;
>   break;

_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

[Alexei Sheplyakov-3]

Hi Jens,

On Sun, Aug 09, 2009 at 10:21:53PM +0200, Jens Vollinga wrote:
> Yes, it improves the allocation,

unsignedvector rettypes;
// rettypes.size() == 0
rettypes.reserve(assocseq.size());
// rettypes.size() == 0 since reserve() does NOT change the size of a vector.
rettypes[i] = cit->return_type();
// Illegal according to the standard. Appears to work with some implementations
// and segfault with others (i.e. m$vc)

So the patch does fix the access beyond the vector boundary (as the commit
message implies).

> and then it does something that looks as if someone prefers to program
> in Python ...

I guess you mean this hunk:

> - switch (rettypes[i] = cit->return_type()) {
> + rettypes[i] = cit->return_type();
> + switch (rettypes[i]) {

It makes code less obscure (IMNSHO), but it's not strictly necessary.
Feel free to skip it.

Best regards,
        Alexei

_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

[Jens Vollinga]

Hi Alexei,

Alexei Sheplyakov schrieb:
> rettypes.reserve(assocseq.size());
> // rettypes.size() == 0 since reserve() does NOT change the size of a vector.
> rettypes[i] = cit->return_type();
> // Illegal according to the standard. Appears to work with some implementations
> // and segfault with others (i.e. m$vc)
>
> So the patch does fix the access beyond the vector boundary (as the commit
> message implies).

oops, yes, sorry, I was confusing reserve with resize ...

Thanks for all the patches. Is there something else you would want to
see in 1.5.4? Otherwise I'll do a release soon.

Regards,
Jens
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel