Problem with large constant character strings

[colin]

I don't understand why you use:

chprintf((BaseSequentialStream*)&SDU1, "%s", menu1); // ALB - does not work with this line

instead of:

chprintf((BaseSequentialStream*)&SDU1, menu1);

I don't think that "%s" is meant to be used on long strings.

Regards

Vicente

There should be no limit on the length of the argument to the "%s" format specifier.

Also, your suggestion is suboptimal for writing this fixed string, because if the fixed string contained, for instance, the text "Press X to display %done", it will interpret the %d as a format specifier and will format the nonexistent argument to chprintf(). You could of course escape the "%" in that string, but since he does not intend to treat the menu as a printf format string, but rather a literal text string, using chprintf(stream, "%s", menu1) is the correct thing to do.

I bet there is some kind of buffering issue in the SDU driver. The first chprintf() writes a small string, which is buffered by SDU driver, and then the second chprintf() tries to write a large string, but there may be a problem in the SDU driver where it doesn't correctly deal with this write. Maybe even a timing dependent issue.

@alb: what if you put a small delay of 1ms to 50ms between the first and second chprintf() calls? Does it fix the issue? That would confirm an SDU driver issue, I think.

[Vic20]

There should be no limit on the length of the argument to the "%s" format specifier.

Also, your suggestion is suboptimal for writing this fixed string, because if the fixed string contained, for instance, the text "Press X to display %done", it will interpret the %d as a format specifier and will format the nonexistent argument to chprintf(). You could of course escape the "%" in that string, but since he does not intend to treat the menu as a printf format string, but rather a literal text string, using chprintf(stream, "%s", menu1) is the correct thing to do.

I bet there is some kind of buffering issue in the SDU driver. The first chprintf() writes a small string, which is buffered by SDU driver, and then the second chprintf() tries to write a large string, but there may be a problem in the SDU driver where it doesn't correctly deal with this write. Maybe even a timing dependent issue.

@alb: what if you put a small delay of 1ms to 50ms between the first and second chprintf() calls? Does it fix the issue? That would confirm an SDU driver issue, I think.

Perhaps there should be no limit, buy when things go wrong it is time to check that "perhaps". That's why I suggested the change. In the end all that counts is to sort-out the poster problem. If its proven that there is no bug associated to a long %s parameter the code could be left as originally was.

You can say that muy proposed change won't work in this case but that has nothing to do with optimization.
Simply I don't think that formatted strings should be used this way.
If you can use two parameters in the chprintf call I think that it is better that using three.
Of course, that implies not using single % chars in the string.

[colin]

You can say that muy proposed change won't work in this case but that has nothing to do with optimization.
Simply I don't think that formatted strings should be used this way.
If you can use two parameters in the chprintf call I think that it is better that using three.
Of course, that implies not using single % chars in the string.

I didn't say that your proposed change won't work, just that the code chprintf(stream, menu) implies that menu is a format string that may contain format specifiers beginning with "%". (If menu is non-constant and read from some external source, this is a significant security hole as well.) If you mean that menu is a fixed string, not a template aka format string, that has format specifiers and associated varargs being passed after it, then you should instead use chprintf(stream, "%s", menu) or another more direct method avoiding chprintf() altogether.

Anyway, let's see what the OP finds out to solve his problem.