"Smith, Barry F." <[email protected]> writes: >> 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
This is just modifying the format string, so not an issue. > 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. I don't think it's possible to write a printf format string that behaves like %g except always includes the decimal point. We could insist on using %e or %.1f style format strings always -- many uses of %g are gratuitous and not actually better for the user. But it would be disruptive and occasionally weird. One alternative would be to escape everything but the %g, count and extend the storage for the %g, snprintf that part, then pass along the rest. But that won't reduced the dirtiness. > 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 <[email protected]> wrote: >> >> "Smith, Barry F." <[email protected]> writes: >> >>>> On Apr 12, 2018, at 3:59 AM, Patrick Sanan <[email protected]> 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 <[email protected]>: >>>> 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 <[email protected]> >>>> 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>
