Hi,

Found another minor one, string literals don't seem to behave as the
documentation says:

   String literals begin with a double quote mark '"' which is followed by
up to 256 printable ASCII characters and are terminated by another double
quote mark.

This string literal contains 126 X's and fails while parsing with a string
too long error:
#declare
Test="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

By the way, the documentation doesn't state how long strings can become, you
can concat strings to over 256 characters, I tried to over 2,000,000 which
seems to work fine. Which also provides the workaround for the bug above.

Still using NT4 with the standard binaries.

Samuel

Post a reply to this message

I still wonder why all these limitations in povray. String literals
limited to 256 characters (or 125 or whatever), nested #includes
limited to about 10, recursive #macros limited to something, number
of parameters to a #macro limited to some number...
  Why?
  It should be very easy to parse a string literal without length limitations
(compilers do). Just count the number of characters, allocate that amount
of memory and copy it there.
  Unlimited #macro recursion and nested #includes should also be possible
(although for some strange reason most compilers have also a nested
#include limit; but afaik there's no limit for recursive macros). Just
make a stack data structure.
  The parameters to a #macro could be a list.

  There's no limitation for number of objects, triangles in a mesh, etc.
Why there should be limitation in this kind of things?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Samuel van Egmond wrote:
> By the way, the documentation doesn't state how long strings can become, you
> can concat strings to over 256 characters, I tried to over 2,000,000 which
> seems to work fine. Which also provides the workaround for the bug above.
Not true..

Try to use the sub (hmm, substring, can't remember it's function now) to
print the string. even if a concat loop works, the print doesn't..

#declare S = "."
#declare N = 100000;
#declare M = 0;
#while(M<N)
  #declare S = concat(S,".")
  #declare M = M +1;
#end

#declare M = 0;
#while(M<N)
  #debug concat("\r",substr(S,0,M))
  #declare M = M +1;
#end


this should show it....

//Spider

Post a reply to this message

You are a very funny spider!!!

Good one....

Samuel.

Spider wrote in message <375### [at] bahnhofse>...
>Samuel van Egmond wrote:
>> By the way, the documentation doesn't state how long strings can become,
you
>> can concat strings to over 256 characters, I tried to over 2,000,000
which
>> seems to work fine. Which also provides the workaround for the bug above.
>Not true..
>
>Try to use the sub (hmm, substring, can't remember it's function now) to
>print the string. even if a concat loop works, the print doesn't..
>
>#declare S = "."
>#declare N = 100000;
>#declare M = 0;
>#while(M<N)
>  #declare S = concat(S,".")
>  #declare M = M +1;
>#end
>
>#declare M = 0;
>#while(M<N)
>  #debug concat("\r",substr(S,0,M))
>  #declare M = M +1;
>#end
>
>
>this should show it....
>
>//Spider

Post a reply to this message

My thoughts exactly,  I just hope I don't run into too many of them.

Samuel

Nieminen Mika wrote in message <37562bc8.0@news.povray.org>...
>  I still wonder why all these limitations in povray. String literals
>limited to 256 characters (or 125 or whatever), nested #includes
>limited to about 10, recursive #macros limited to something, number
>of parameters to a #macro limited to some number...
>  Why?
>  It should be very easy to parse a string literal without length
limitations
>(compilers do). Just count the number of characters, allocate that amount
>of memory and copy it there.
>  Unlimited #macro recursion and nested #includes should also be possible
>(although for some strange reason most compilers have also a nested
>#include limit; but afaik there's no limit for recursive macros). Just
>make a stack data structure.
>  The parameters to a #macro could be a list.
>
>  There's no limitation for number of objects, triangles in a mesh, etc.
>Why there should be limitation in this kind of things?
>
>--
>main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
>):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Samuel van Egmond wrote:
> 
> You are a very funny spider!!!
> 
> Good one....
> 
> Samuel.
LMAO .... 
Actually, there are several bugs in the concat() code.. parser not
caring for end ) in some cases, not error reporting and some other
stuff.

//Spider

Post a reply to this message

Nieminen Mika wrote:

>   Why?
>   It should be very easy to parse a string literal without length limitations
> (compilers do). Just count the number of characters, allocate that amount

Probably because nobody wanted to write such a function,
ANSI libc.a does not contain one, and POV was written in a
time before GNU hackers told that all limits are evil.
AFAIK glibc has an extension (getline) which does the job.

Ralf

Post a reply to this message

Spider wrote:

> Samuel van Egmond wrote:
> >
> > You are a very funny spider!!!
> >
> > Good one....
> >
> > Samuel.
> LMAO ....
> Actually, there are several bugs in the concat() code.. parser not
> caring for end ) in some cases, not error reporting and some other
> stuff.
>
> //Spider

so, should I go in and tweak all the string handling to deal in Unicode,
and also take out the limits while I'm in there?

Post a reply to this message

Ralf Muschall <rmu### [at] t-onlinede> wrote:
: Probably because nobody wanted to write such a function,
: ANSI libc.a does not contain one, and POV was written in a
: time before GNU hackers told that all limits are evil.
: AFAIK glibc has an extension (getline) which does the job.

  filepos=ftell(InFile);
  for(i=StartingQuoteIndex+1; getc(InFile)!='"'; i++);
  fseek(filepos);
  char* String=malloc(i-StartingQuoteIndex-1);
  fgets(String, i-StartingQuoteIndex-1, InFile);

  What's so difficult here?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

"Jon A. Cruz" wrote:
> 
> Spider wrote:
> 
> > Samuel van Egmond wrote:
> > >
> > > You are a very funny spider!!!
> > >
> > > Good one....
> > >
> > > Samuel.
> > LMAO ....
> > Actually, there are several bugs in the concat() code.. parser not
> > caring for end ) in some cases, not error reporting and some other
> > stuff.
> >
> > //Spider
> 
> so, should I go in and tweak all the string handling to deal in Unicode,
> and also take out the limits while I'm in there?
please do! 

//Spider

Post a reply to this message

On 4 Jun 1999 03:19:12 -0500, Nieminen Mika wrote:
>Ralf Muschall <rmu### [at] t-onlinede> wrote:
>: Probably because nobody wanted to write such a function,
>: ANSI libc.a does not contain one, and POV was written in a
>: time before GNU hackers told that all limits are evil.
>: AFAIK glibc has an extension (getline) which does the job.
>
>  filepos=ftell(InFile);
>  for(i=StartingQuoteIndex+1; getc(InFile)!='"'; i++);
>  fseek(filepos);
>  char* String=malloc(i-StartingQuoteIndex-1);
>  fgets(String, i-StartingQuoteIndex-1, InFile);
>
>  What's so difficult here?

This, from the docs:

 Note if you need to specify a quote mark in a string literal you must precede 
 it with a  backslash. For example
    "Joe said \"Hello\" as he walked in."
   is converted to
   Joe said "Hello" as he walked in.
 If you need to specify a backslash, most of the time you need do nothing 
 special. However  if the string ends in a backslash, you will have to specify 
 two. For example:
   "This is a backslash \ and so is this\\"
   Is converted to:
   This is a backslash \ and so is this\

Not that it's insurmountable or anything, but it does make the job a little 
more interesting than what you have there.

Post a reply to this message

On Thu, 03 Jun 1999 19:45:59 -0700, Jon A. Cruz wrote:
>Spider wrote:
>
>> Samuel van Egmond wrote:
>> >
>> > You are a very funny spider!!!
>> >
>> > Good one....
>> >
>> > Samuel.
>> LMAO ....
>> Actually, there are several bugs in the concat() code.. parser not
>> caring for end ) in some cases, not error reporting and some other
>> stuff.
>>
>> //Spider
>
>so, should I go in and tweak all the string handling to deal in Unicode,
>and also take out the limits while I'm in there?

No, you should tweak it to work in whatever the current encoding is.  
Not that there's any distinction, for now, but what if someone adds
a multibyte encoding later?  Keep in mind that that means the encoding 
has to be specified first, because it affects parsing, which is not like 
all the other global_settings.

Post a reply to this message

On 4 Jun 1999 09:58:51 -0500, Ron Parker wrote:
>No, you should tweak it to work in whatever the current encoding is.  
>Not that there's any distinction, for now, but what if someone adds
>a multibyte encoding later?  Keep in mind that that means the encoding 
>has to be specified first, because it affects parsing, which is not like 
>all the other global_settings.

Doh!  Of course there's a distinction.  A single-byte encoding could
easily contain the first byte of a double- or triple-byte UTF-8 character, 
so you'd have to be sensitive to encoding type even with the current choices.

Post a reply to this message

Ron Parker wrote:

> On 4 Jun 1999 09:58:51 -0500, Ron Parker wrote:
> >No, you should tweak it to work in whatever the current encoding is.
> >Not that there's any distinction, for now, but what if someone adds
> >a multibyte encoding later?  Keep in mind that that means the encoding
> >has to be specified first, because it affects parsing, which is not like
> >all the other global_settings.
>
> Doh!  Of course there's a distinction.  A single-byte encoding could
> easily contain the first byte of a double- or triple-byte UTF-8 character,
> so you'd have to be sensitive to encoding type even with the current choices.

But here's where the problems start to creep in.

If you start to allow arbitrary encodings, which do you use? A common thing for
programs in the past has been to use the default multibyte encoding of the
platform it is running on. That's nice for an isolated user, but breaks down
when you start to go global.

The old multibyte true-type patch did just this. It was for exactly this reason
that the patch was useable only on systems that were natively multibyte such as
Japanese or Chinese. So you'd get different results if you ran on a Chinese
system than if you ran on a Japanese system, OR it would just fail completely.

Probably the only way to keep the .pov files portable and generating identical
results on any platform (which I think is one of the design goals of POV-Ray)
would be to include the encoding support in POV-Ray. But, you can't include
everything, so where do you draw the line?

In my Unicode patch I have it converting only after text is passed down in for
generating objects, so the encoding is deferred (this was mainly to avoid
changing all the text handling). However, I did do a few base encodings.

We could just change things to handle the current US-ASCII and Unicode (UTF-8,
UTF-16). For nicer user support we could then add CP-1252 (Windows) and
MacRoman (but Mac has lots of problems). Notepad on NT can do Unicode versions
of text files, and for the rest, we could probably push the conversion burden
out onto the end-user (e.g. if you want to render Klingon text, you are
responsible for converting your Klingon into Unicode before sending it off to
POV-Ray.) If the entire program was changed to be based on Unicode instead of
single-byte text, this might help.

But then... what happens to all the text manipulation routines? Are end-user
scripts dependent on one character=one byte? What compatibility issues could
this cause? Hmmm....



(followups set to povray.programming)

Post a reply to this message

The code was just to give the idea, not to be the perfect final code
to directly copy-paste into the povray source.
  Of course you have to add various checkings in there, but you got the
idea, didn't you?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Mika wrote:

[code which seeks back deleted]
>   What's so difficult here?

It is not difficult (it wouldn't be even in a version
which does not seek - just use fread into a malloced
buffer and double the size of that with realloc until done),
just in the past nobody cared about such problems.

For a test, try
find . -name '*.[ch]' -exec grep scanf {} \;
in the source tree of some program.

That's what gave us the internet worm and gives us
crashing MS stuff every day, and "Smashing the stack for
fun and profit" (title of a paper by AlephOne).
The BSD guys claim to have cleaned this kind of bugs out
of their code, otherwise I believe the whole world is still
messy.

Ralf

Post a reply to this message