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