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 <[email protected]>: > On Thu, Apr 12, 2018 at 9:48 AM, Smith, Barry F. <[email protected]> > wrote: > >> >> >> > 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(). >> > 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 <[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> >> > >> > >> > >> >> >
