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

   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