On 10/13/21 10:44 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 10/9/21 3:49 AM, jr wrote:
>>> William F Pokorny <ano### [at] anonymousorg> wrote:
>>>> On 10/6/21 5:01 AM, jr wrote:
>>>>> ...
>>>> This a bug is basically the same as the radiosity file append bug.
>>           x
>>> a known issue, ok.  thanks.
>>
>> No. Well, it perhaps now is.
> 
> good, I think.  :-)
> 
> 
>> ...
>> I've not spent much time with POV-Ray's IO code.
> 
> sounds like opening a can of worms, only to find a multi-pack of can of worms
> inside..  think it .. bad not to have access to (tech) notes dealing with design
> etc of the "new" IO class.  bazaar, huh?!
> 
> coincidentally, have just posted a new macro in p.text.scene-files, 'Filed()', a
> CSV file handler, hope you'll find that useful when "stirring the worms" ;-).
> 

Thanks jr, I'll use it do some testing.


--- An update

+ Using 'if ((fid != nullptr) && (*fid))' is frequently proving useful.

+ My additional concern in radiosity.cpp's Save was justified. We are 
sometimes running the Save() code per render block(1) - without 
complaint from POV-Ray - when we in fact don't have a valid file handle. 
This particular issue is fixed in povr.

+ In many places finding the IO checking to be correct, which is good 
news. The less good news is, in a number of those situations, the code 
to generate messages for the end user is commented out or too generic to 
be of much help(2).

+ Unfortunately, we are often failing in complete silence. Stuff 
sometimes runs cleanly to all appearances, when there are in fact user 
file specification issues.

+ With povr, I've checked in a set of updates to add and/or improve 
warning/error messages both where the file IO checking was OK and where 
it was not. For example, I made changes to the previous randiosity.cpp 
samples file fix so that we now generate messages related to the 
radiosity samples file usage.

+ I think I now understand some of what changed v3.7 to v3.8 to 
introduce issues with the fopen keyword and invalid files.

+ I've got doubts about getting everything scrubbed anytime soon. Given 
the code (the IO class usage) is different file to file, use to use over 
a large code base. I don't currently see any easy way to flag potential 
problems aside from trying things and reviewing code.

Bill P.

(1) - Yep, and with this, we picked up a related puzzle with radiosity. 
Parts of the samples related code is running all the time! Meaning 
whether we have radiosity in the scene or not, whether the quality level 
supports radiosity or not - this samples code runs for each render 
block. The 'additional radiosity concern,' fixed now in the povr branch, 
extended what code was always run due testing for only != nullptr 
(testing true for a valid file handle). A puzzle / optimization for 
another day.

(2) - I learned yesterday the state file location is derived from the 
output image location! I wrongly thought the state file (aka continue 
trace log) was always local to where the render command was issued, but 
it ends up wherever you write the output image file. Further, if your 
output image location is bogus, the error message seen relates to the 
state file and not the output image file - which is confusing. I changed 
the error messages in a way which I hope will help.

Post a reply to this message