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