I was trying to make a pov script which could create its own .df3 file.
However, this seems to be impossible since for some reason povray refuses
to write the value 0 to the file. Every other value (1-255) can be written
but not 0.
  What's going on here? Is it a bug or an intentional feature?

-- 
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

On 20 Oct 1999 10:49:11 -0400, Nieminen Juha wrote:
>  I was trying to make a pov script which could create its own .df3 file.
>However, this seems to be impossible since for some reason povray refuses
>to write the value 0 to the file. Every other value (1-255) can be written
>but not 0.
>  What's going on here? Is it a bug or an intentional feature?

Sounds like a bug to me.  I'd wager that #write uses fprintf, which will
terminate when it sees the zero.

Post a reply to this message

On 20 Oct 1999 10:49:11 -0400, Nieminen Juha
<war### [at] punarastascstutfi> wrote:

>  I was trying to make a pov script which could create its own .df3 file.
>However, this seems to be impossible since for some reason povray refuses
>to write the value 0 to the file. Every other value (1-255) can be written
>but not 0.
>  What's going on here? Is it a bug or an intentional feature?

It's a limitation of the function used (fprintf()?). I hit this wall
about a year ago and thankfully PoD made his tga2df3 utility just in
time.

The file I/O directives were designed to work with ASCII files -- ini,
pov, inc, txt etc. to help carry data between frames, change ini
settings etc. You know that in an ASCII file EOF is '\0' so you see
how the limitation of fprintf() could easily have been overseen by the
Team.


Peter Popov
ICQ: 15002700

Post a reply to this message

Peter Popov wrote:

> On 20 Oct 1999 10:49:11 -0400, Nieminen Juha
> <war### [at] punarastascstutfi> wrote:
>
> >  I was trying to make a pov script which could create its own .df3 file.
> >However, this seems to be impossible since for some reason povray refuses
> >to write the value 0 to the file. Every other value (1-255) can be written
> >but not 0.
> >  What's going on here? Is it a bug or an intentional feature?
>
> It's a limitation of the function used (fprintf()?). I hit this wall
> about a year ago and thankfully PoD made his tga2df3 utility just in
> time.
>
> The file I/O directives were designed to work with ASCII files -- ini,
> pov, inc, txt etc. to help carry data between frames, change ini
> settings etc. You know that in an ASCII file EOF is '\0' so you see
> how the limitation of fprintf() could easily have been overseen by the
> Team.

Actually, an EOF is -1, which is different. Or for an old-fashioned text file,
Ctrl-Z is the end of file marker.

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

Ron Parker <par### [at] fwicom> wrote:
: Sounds like a bug to me.  I'd wager that #write uses fprintf, which will
: terminate when it sees the zero.

  Why it doesn't print it like: fprintf(file,"%c",value);

-- 
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 Juha <war### [at] punarastascstutfi> wrote:
>   I was trying to make a pov script which could create its own .df3 file.
> However, this seems to be impossible since for some reason povray refuses
> to write the value 0 to the file. Every other value (1-255) can be written
> but not 0.
>   What's going on here? Is it a bug or an intentional feature?
>

Under DOS it also happily expands chr(10) to 13 and 10 for obvious
reasons - this is text output after all...

There's a function Parse_Write() in tokenize.c
which calls Parse_Formatted_String() in express.c.
Even a single character is represented as a whole string internally,
so chr(0) is not written because it's interpreted as end-of-string.

BTW I found another bug in the above function.
Try a string ending with '\\' either in a file write or in one of the
console output streams:
Most of the time one gets garbage appended to the string,
because the pointer to the last character in the source string is
incremented even if this character is the null-byte.


Gerald
ger### [at] aonat

Post a reply to this message

On Wed, 20 Oct 1999 23:44:18 -0700, "Jon A. Cruz"
<jon### [at] geocitiescom> wrote:

>Actually, an EOF is -1, which is different. Or for an old-fashioned text file,
>Ctrl-Z is the end of file marker.

What lead me into thinking it was "\0"?! Anyway, I've only checked
against it and didn't actually work with its value. Thanks for the
clarification, I'll have it in mind.

Follow-ups to this post (if any) set to povray.programming


Peter Popov
ICQ: 15002700

Post a reply to this message

Gerald K. Dobiasovsky wrote in message <380f6e5d@news.povray.org>...
>BTW I found another bug in the above function.
>Try a string ending with '\\' either in a file write or in one of the
>console output streams:
>Most of the time one gets garbage appended to the string,
>because the pointer to the last character in the source string is
>incremented even if this character is the null-byte.


That would explain the problems I'm having with the virus I'm writing!

Mark

Post a reply to this message

Mark Wagner <mar### [at] gtenet> wrote:
>
> That would explain the problems I'm having with the virus I'm writing!
>

And then cash in big by distributing antivirus POV-scripts?
;)

Post a reply to this message

Gerald K. Dobiasovsky wrote in message <380f6e5d@news.povray.org>...
>BTW I found another bug in the above function.
>Try a string ending with '\\' either in a file write or in one of the
>console output streams:
>Most of the time one gets garbage appended to the string,
>because the pointer to the last character in the source string is
>incremented even if this character is the null-byte.


I found a fix for this bug (haven't been able to test it yet, though).

In Parse_Formatted_String in file express.c, replace the line
     while (*src != '\0')
with the line
     while (*dest != '\0')
and the line
          case '\0': *dest=0x5c; break;
with the line
          case '\0': *dest=0x5c; *(dest+1) = '\0'; break;
and increast the size of the 'buff' array to MAX_STRING_INDEX*2+1

This should solve the problem.

Mark

Post a reply to this message