Invalid string (misused <...> or {...}, or literal is too long) c11 13788

vlada_vukicevic · February 26, 2022, 9:46pm

The latest update of clarion 13788 is unusable for me, in many places the compiler reports an error / Invalid string (misused <…> or {…}, or literal is too long) /. Attached is a screenshot, the previous query works without problems, what is the problem with this starting from the 1554 line I do not know.

jslarve · February 26, 2022, 10:40pm

I wonder if the “<0” is being interpreted as part of <0>. Try putting a space between?

CarlBarnes · February 26, 2022, 10:42pm

A Less Than symbol < in Clarion String Literals is supposed to be doubled << unless it is encoding ASCII codes like <13,10> . The compiler does try to spot singles next to letters (non-numbers) and accept those i.e. not error e.g. your <= do not error.

In line 1558 you have <0 that the compiler will think is an unfinished ASCII code <0> so you get the error. Double that Less Than i.e. change <0 to <<0.

vlada_vukicevic · February 26, 2022, 11:58pm

Thanks Carl, when I replace < with << no more problems. With 13768 I didn’t have that problem, only after the update to 13788 did it happen.

Best regards

jslarve · February 27, 2022, 5:32pm

It sounds like they’ve reverted some of the compiler behavior to the “old way”? Someone else is experiencing this issue on the NGs.

I have a vague memory of when the doubling up was needed more regularly than it was in more recent Clarion builds. Seems like it was relaxed after perhaps C4 or 5, so that unambiguous use of a solo < was permitted.

This program compiles fine in C11, but not the latest C11.1. Seems like a significant change in behavior.

 PROGRAM
 
   MAP
   END
   
S STRING('<0')

  CODE

jslarve · February 27, 2022, 5:36pm

This compiles fine in the latest build:

 PROGRAM
 
   MAP
   END
   
S STRING('< x0')

  CODE

This does not. :

 PROGRAM
 
   MAP
   END
   
S STRING('< 0x')

  CODE

Jane · February 27, 2022, 6:23pm

Just curious, Jeff.

What happens to your example if you try wrapping in the new “eol_is_space” pragma they added?

jf

jslarve · February 27, 2022, 6:46pm

I can’t seem to make this error happy by using that switch. Tried in code (including the semicolon) too.

Even this produces the error (with a CRLF before the numeric character):

  PRAGMA ('option(eol_is_space => on)')
  S ='<  
  0x';
  PRAGMA ('option(eol_is_space => off)')

BUT put an alpha character somewhere after the <, then it is A-OK.

  PRAGMA ('option(eol_is_space => on)')
  S ='<  x
  0x';
  PRAGMA ('option(eol_is_space => off)')

Jane · February 27, 2022, 6:53pm

Does the switch seem to make any difference in your experiments?

I was just guessing that the compiler change made to support that would affect string parsing in general.

jslarve · February 27, 2022, 6:54pm

It did not seem to affect the compiler behavior with regard to that bug.

But without the switch, the examples in my previous post would not have compiled.

yoram · February 27, 2022, 9:24pm

When I compile my app in 13788, I get an error for in the last three of these 5 lines in abprpdf.clw:

   CharToReplace[17]= CHR(184);ReplacedBy[17]= ')<F8>(';LenReplacedBy[17]= 6
   CharToReplace[18]= CHR(191);ReplacedBy[18]= ')<E6>(';LenReplacedBy[18]= 6
   CharToReplace[19]= CHR(208);ReplacedBy[19]= ')<8A>(';LenReplacedBy[19]= 6
   CharToReplace[20]= CHR(222);ReplacedBy[20]= ')<8E>(';LenReplacedBy[20]= 6
   CharToReplace[21]= CHR(254);ReplacedBy[21]= ')<9E>(';LenReplacedBy[21]= 6

The error is “Invalid Number”. This is from the SoftVelocity provided library for PDF, not my code. The error is the 8A, 8E, and 9E. Clearly the compiler used to recognize that as hex in 13768 but in 13788 it thinks it’s (bad) decimal!

vlada_vukicevic · February 27, 2022, 9:31pm

In my example the sign < was used as a sign for less than (for example Number1 < 1500). Now I’ve learned that in SQL Filter or when I use a query with prop:sql inside a string instead of a less than < I use << character and everything is ok.

vlada_vukicevic · February 27, 2022, 9:59pm

I solved the problem by removing that piece of code from abprpdf.clw, but I don’t know how it affects the rest.

   CharToReplace[18]= CHR(191);ReplacedBy[18]= ')<E6>(';LenReplacedBy[18]= 6
			OMIT('***END***')
   CharToReplace[19]= CHR(208);ReplacedBy[19]= ')<8A>(';LenReplacedBy[19]= 6
   CharToReplace[20]= CHR(222);ReplacedBy[20]= ')<8E>(';LenReplacedBy[20]= 6
   CharToReplace[21]= CHR(254);ReplacedBy[21]= ')<9E>(';LenReplacedBy[21]= 6
			***END***

jslarve · February 27, 2022, 10:17pm

That solves your x/y problem, but doesn’t fix the actual problem.

I think you already had a bug in your code, but it didn’t surface until the new Clarion compiler bug told you about it.

e6, I assume, is supposed to represent a hexadecimal number. It needs to be represented as e6H.

In addition, if you were to add an “H” to all of the remaining hex, you should be able to compile it OK without the OMIT.

The reason those 3 lines don’t compile is that the first character after the < is numeric. Since “8A” is not a valid decimal number, you get the compile error. So tell it that you mean hex with “8Ah”, and it should be OK.

Mike_Duglas · February 27, 2022, 10:45pm

I think “8A” doesn’t mean a hex code of a character, it means 2 characters “8A” in a PDF token “)<8A>(”: see next assignment LenReplacedBy[19]= 6: 6 is a number of characters in “)<8A>(”.

jslarve · February 27, 2022, 11:00pm

Thanks Mike, plus extra characters so I can post this message.

yoram · February 28, 2022, 12:18am

I replaced them with the decimal values:

   CharToReplace[19]= CHR(208);ReplacedBy[19]= ')<138>(';LenReplacedBy[19]= 6 !yb bug workaround
   CharToReplace[20]= CHR(222);ReplacedBy[20]= ')<142>(';LenReplacedBy[20]= 6 !yb bug workaround
   CharToReplace[21]= CHR(254);ReplacedBy[21]= ')<158>(';LenReplacedBy[21]= 6 !yb bug workaround

yoram · February 28, 2022, 12:22am

Oh, I just read Mike Duglas’ post; I guess my workaround is wrong then.

vitesse · February 28, 2022, 1:19am

   CharToReplace[17]= CHR(184);ReplacedBy[17]= ')<<F8>(';LenReplacedBy[17]= 6
   CharToReplace[18]= CHR(191);ReplacedBy[18]= ')<<E6>(';LenReplacedBy[18]= 6
   CharToReplace[19]= CHR(208);ReplacedBy[19]= ')<<8A>(';LenReplacedBy[19]= 6
   CharToReplace[20]= CHR(222);ReplacedBy[20]= ')<<8E>(';LenReplacedBy[20]= 6
   CharToReplace[21]= CHR(254);ReplacedBy[21]= ')<<9E>(';LenReplacedBy[21]= 6

yes I think simply double up the < to be <<

vlada_vukicevic · February 28, 2022, 9:01am

This is not my code, this is the abprpdf.clw code that comes with SV PDFGenerator. After the last update 13788, this problem occurred. The error is in the PDFGeneratorClass.EscapeValues procedure. If you do not use CHARSET: BALTIC then you can eject these three lines of code. I’ve had a problem with CHARSET: EASTEUROPE for a long time, PDFGenerator can’t display the characters Đ Č Ć correctly, while Š Ž displays them correctly. Does anyone know how to solve this problem?