[petsc-dev] [petsc-users] PetscPrintf

[Patrick Sanan]

How about the logic of this analysis?

1. We are trying to use the same functions (in particular, PetscVFPrintf)
for two purposes:
   a. printing error messages (don't want to malloc)
   b. use by public API printing functions (don't want length restrictions)

2. Right now, PetscVFPrintf works fine for a but not for b. We could make
it work for b and not for a by malloc'ing a longer string.

3. Printing from error handlers happens through PetscErrorPrintf (default :
http://www.mcs.anl.gov/petsc/petsc-dev/src/sys/error/errtrace.c.html#PetscErrorPrintfDefault
), so if there's a special requirement for printing error messages, we can
impose it here.

A solution could then be something which skips the malloc only when
printing an error, e.g.

1. Add an argument to PetscVFPrintf (say "PetscBool noMalloc") [1]
2. API (PetscPrintf(), etc.) functions use noMalloc = PETSC_FALSE
3. error functions (PetscErrorPrintf() ) functions use noMalloc =
PETSC_TRUE


[1] And probably do the same thing in PetscVSNPrintf since, as Dr. Zhang
pointed out, this could also call malloc while handling an error, if the
string was long enough




2018-04-13 15:59 GMT+02:00 Junchao Zhang <jczhang at mcs.anl.gov>:

> On Thu, Apr 12, 2018 at 9:48 AM, Smith, Barry F. <bsmith at mcs.anl.gov>
> wrote:
>
>>
>>
>> > On Apr 12, 2018, at 3:59 AM, Patrick Sanan <patrick.sanan at 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().
>>
> PetscVSNPrintf does still contain a malloc "122  ierr      =
> PetscMalloc1(oldLength, &newformat);CHKERRQ(ierr);"
> Also, vsnprintf returns "the number of characters that would have been
> written if n had been sufficiently large". I don't know why you void'ed
> it.
> We can not make the 8K chars a requirement since users don't know how many
> chars they want to print upfront.
> Anyway, crash is better than silent errors.
>
>>
>>    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.chan at 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.chan at 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>
>> >
>> >
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20180415/f0b252ea/attachment.html>