> Is the postprocessing of output in PetscVSNPrintf really necessary?

PetscVSNPrintf does two things

1) handles %D to have a common way of printing PetscInt regardless of if they 
are 32 or 64 bit integers

2) insures that all floating point numbers printed have a . in them so 
Petscdiff can accurately determine what is a 
floating point number in output (standard C formats don't put the . in floating 
point numbers like 1. that don't need them. I could not find 
any decent numerical diff for PETSc output to use in place of our cumbersome 
home-brew thing.

If there are alternative ways of handling 1) and 2) then PetscVSNPrintf() and 
its cumbersomeness are not needed.

Barry

Note that PetscVSNPrintf() does not handle printing of PetscReal, we have to 
manually put a caste of (double) in the calling sequence (for __float128). I 
tried to add this support with %G but gave up because it was a rat hole.





> On Apr 12, 2018, at 8:22 PM, Jed Brown <j...@jedbrown.org> wrote:
> 
> "Smith, Barry F." <bsm...@mcs.anl.gov> writes:
> 
>>> On Apr 12, 2018, at 3:59 AM, Patrick Sanan <patrick.sa...@gmail.com> wrote:
>>> 
>>> I also happened to stumble across this yesterday. Is the length restriction 
>>> for the default printer (l assume from the array of 8*1024 chars in 
>>> PetscVFPrintfDefault() ) intended behavior to be documented, or a bug to be 
>>> fixed?
>> 
>>     You could call it either. My problems are 
>> 
>> 1) that given a format string I don't know in advance how much work space is 
>> needed so cannot accurately malloc, for sure, enough space
>> 
>> 2) since this can be called in an error handler I really don't want it 
>> calling malloc().
>> 
>>   Hence it lives in this limbo. I don't even know a way to add a good error 
>> checking that detects if the buffer is long enough. All in all it is bad 
>> ugly code, any suggestions on improvements would be appreciated.
> 
> Is the postprocessing of output in PetscVSNPrintf really necessary?
> Without it, you would call vfprintf instead of vsnprintf followed by
> fprintf("%s", string) [1].
> 
> 
> [1] fputs would be preferable.
> 
>> 
>>   Barry
>> 
>>> 
>>> 2018-04-12 2:16 GMT+02:00 Rongliang Chen <rongliang.c...@gmail.com>:
>>> Thanks Barry. I found petsc-3.6 and older versions did not have this 
>>> restriction.
>>> 
>>> Best,
>>> Rongliang
>>> 
>>> 
>>> On 04/12/2018 07:22 AM, Smith, Barry F. wrote:
>>>   Yes, PetscPrintf() and related functions have a maximum string length of 
>>> about 8000 characters.
>>> 
>>>    Barry
>>> 
>>> 
>>> On Apr 11, 2018, at 6:17 PM, Rongliang Chen <rongliang.c...@gmail.com> 
>>> wrote:
>>> 
>>> Dear All,
>>> 
>>> 
>>> When I tried to print a long string using PetscPrintf() I found that it 
>>> truncated the string. Attached is a simple example for this (run with 
>>> single processor). I used PetscPrintf() and printf() to print the same 
>>> string and the printf() seems OK. I am using petsc-3.8.4.
>>> 
>>> 
>>> Best,
>>> 
>>> Rongliang
>>> 
>>> <ex111.c>

Reply via email to