Very small step in the correct direction 
https://bitbucket.org/petsc/petsc/pull-requests/931/barry-bugfix-petscformatconvert/diff


> On Apr 15, 2018, at 5:41 AM, Patrick Sanan <patrick.sa...@gmail.com> wrote:
> 
> 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 <jczh...@mcs.anl.gov>:
> On Thu, Apr 12, 2018 at 9:48 AM, Smith, Barry F. <bsm...@mcs.anl.gov> wrote:
> 
> 
> > 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().
> 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.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