Re: [ft] FT_Done_Face Should Not Return An Error

>>> * For backward compability, it should continue to return >>> FT_Err_Ok. >> >> It should return what it already returns. > > But it returns an error code. But above you said it “shouldn’t > return an error code at all”. So here you saying it *should* return > an error code. You sound as

Re: [ft] FT_Done_Face Should Not Return An Error

On Fri, 11 May 2018 10:03:26 +0900, suzuki toshiya wrote: > ... the maintainer cannot introduce the change breaking > the backward compatibility ... Which is why I suggested a change that would *not* break backward incompatibility. Whatever code that might actually exist that checks for an error

Re: [ft] FT_Done_Face Should Not Return An Error

> Otherwise it’s going to be very difficult conducting > a coherent conversation with you. What Werner think as the best design could be different from what the current implementation does. Even if it is not the best design, the maintainer cannot introduce the change breaking the backward

Re: [ft] FT_Done_Face Should Not Return An Error

On Thu, 10 May 2018 00:55:42 +0200 (CEST), Werner LEMBERG wrote: > On Thu, 10 May 2018 10:29:11 +1200, Lawrence D'Oliveiro wrote: >> >> On Wed, 09 May 2018 14:11:19 +0200 (CEST), Werner LEMBERG wrote: >>> >>> IMHO, `FT_Done_Face' shouldn't return an error code >>> at all. >> >> Glad you

Re: [ft] FT_Done_Face Should Not Return An Error

On 5/10/2018 12:29 AM, Lawrence D'Oliveiro wrote: On Wed, 09 May 2018 14:11:19 +0200 (CEST), Werner LEMBERG wrote: IMHO, `FT_Done_Face' shouldn't return an error code at all. Glad you finally agree. Why are so exceptionally persistent? Please help me understand your primary motivation

Re: [ft] FT_Done_Face Should Not Return An Error

>> IMHO, `FT_Done_Face' shouldn't return an error code >> at all. > > Glad you finally agree. So how to fix it? IMHO, there is nothing to fix. > * For backward compability, it should continue to return FT_Err_Ok. It should return what it already returns. > * So what should the code do if the

Re: [ft] FT_Done_Face Should Not Return An Error

On Wed, 09 May 2018 14:11:19 +0200 (CEST), Werner LEMBERG wrote: > IMHO, `FT_Done_Face' shouldn't return an error code > at all. Glad you finally agree. So how to fix it? * For backward compability, it should continue to return FT_Err_Ok. * So what should the code do if the FT_List_Find call

Re: [ft] FT_Done_Face Should Not Return An Error

>> Again, this is a hypothetical, bad example. No need actually to >> discuss this further :-) > > So what would you consider to be a GOOD example of checking for an > error from FT_Done_Face? I don't have one. IMHO, `FT_Done_Face' shouldn't return an error code at all. Werner

Re: [ft] FT_Done_Face Should Not Return An Error

On Mon, 07 May 2018 09:55:51 +0200 (CEST), Werner LEMBERG wrote: > Again, this is a hypothetical, bad example. No need actually to discuss this > further :-) So what would you consider to be a GOOD example of checking for an error from FT_Done_Face?

Re: [ft] FT_Done_Face Should Not Return An Error

>> With `trusting' I mean that the code controls `FT_New_Face'. For >> example, a plug-in provided by the user might call `FT_New_Face', >> delegating the deallocation to the program core. In this case the >> program core cannot trust that the user module always does the >> right thing. > >

Re: [ft] FT_Done_Face Should Not Return An Error

On Mon, 07 May 2018 09:01:34 +0200 (CEST), Werner LEMBERG wrote: > With `trusting' I mean that the code controls `FT_New_Face'. For > example, a plug-in provided by the user might call `FT_New_Face', > delegating the deallocation to the program core. In this case the > program core cannot trust

Re: [ft] FT_Done_Face Should Not Return An Error

On Mon, 07 May 2018 08:18:35 +0200 (CEST), Werner LEMBERG wrote: > On Mon, 7 May 2018 17:48:17 +1200, Lawrence D'Oliveiro wrote: >> >> NULL should be perfectly valid -- it simply indicates the object was >> never allocated. > > Well, yes – if you trust the source. Does FreeType “trust its

Re: [ft] FT_Done_Face Should Not Return An Error

>> You would only check the return value of `FT_Done_Face' if your >> code gets an `FT_Face' handle that it doesn't manage by itself >> (rather unlikely, but who knows). In this situation it could >> happen that the handle is NULL, and this should be reported back – >> not because `FT_Done_Face'

Re: [ft] FT_Done_Face Should Not Return An Error

On Mon, 07 May 2018 07:33:16 +0200 (CEST), Werner LEMBERG wrote: > You would only check the return value of `FT_Done_Face' if your code > gets an `FT_Face' handle that it doesn't manage by itself (rather > unlikely, but who knows). In this situation it could happen that the > handle is NULL, and

Re: [ft] FT_Done_Face Should Not Return An Error

On Mon, 7 May 2018 14:34:26 +0900, suzuki toshiya wrote: > Thus, making FreeType abort immediately by a bad > font, it can make some environment quite inconvenient. I’m not sure where you get such an idea from... ___ Freetype mailing list

Re: [ft] FT_Done_Face Should Not Return An Error

I guess, if the original request were something like: "there are so many existing applications which ignore the errors from FT_Done_Face or FT_Done_Library. I know no concrete examples of these errors, I want to collect the information on these errors, so I want to have some hook into these

Re: [ft] FT_Done_Face Should Not Return An Error

>> You only get an error code if `FT_Done_Face' is called with an >> invalid handle, something which doesn't happen in a normal FreeType >> workflow. > > What are you supposed to do when it does happen? You would only check the return value of `FT_Done_Face' if your code gets an `FT_Face'

Re: [ft] FT_Done_Face Should Not Return An Error

On Sun, 6 May 2018 23:33:16 +0200, Gregor Mückl wrote: > On 5/6/2018 10:54 PM, Lawrence D'Oliveiro wrote: > >> In the process of recovering from the error in disposing of the >> first one, do you try to dispose of the second one? > > This could potentially happen ... I know it can

Re: [ft] FT_Done_Face Should Not Return An Error

On Mon, 07 May 2018 06:55:27 +0200 (CEST), Werner LEMBERG wrote: > You only get an error code if `FT_Done_Face' is called with an > invalid handle, something which doesn't happen in a normal FreeType > workflow. What are you supposed to do when it does happen?

Re: [ft] FT_Done_Face Should Not Return An Error

On Sun, 6 May 2018 22:07:53 +0200, Gregor Mückl wrote: > On 5/6/2018 9:56 PM, Lawrence D'Oliveiro wrote: > >> On Sun, 6 May 2018 09:47:19 +0200, Gregor Mückl wrote: >>> >>> Also, on the way up to the exception handler in main(), stack >>> unwinding causes destructors of various objects to be

Re: [ft] FT_Done_Face Should Not Return An Error

On 5/6/2018 9:56 PM, Lawrence D'Oliveiro wrote: On Sun, 6 May 2018 09:47:19 +0200, Gregor Mückl wrote: The important part here is that the constructor of gltb::Error records the actual runtime callstack of where it was executed, that is, how the throw statement was reached in the exection flow

Re: [ft] FT_Done_Face Should Not Return An Error

On Sun, 6 May 2018 09:47:19 +0200, Gregor Mückl wrote: > The important part here is that the constructor of gltb::Error > records the actual runtime callstack of where it was executed, that > is, how the throw statement was reached in the exection flow of the > program. And its asFormattedText

Re: [ft] FT_Done_Face Should Not Return An Error

On 5/6/2018 10:15 AM, Lawrence D'Oliveiro wrote: On Sun, 6 May 2018 09:47:19 +0200, Gregor Mückl wrote: if(FT_Done_Face(face != 0) { You got to be kidding me. OK, there's a brace missing. That doesn't change anything I explained below.

Re: [ft] FT_Done_Face Should Not Return An Error

On Sun, 6 May 2018 09:47:19 +0200, Gregor Mückl wrote: > if(FT_Done_Face(face != 0) { You got to be kidding me. ___ Freetype mailing list Freetype@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

On 5/6/2018 1:19 AM, Lawrence D'Oliveiro wrote: On Sun, 6 May 2018 00:11:12 +0200, Gregor Mückl wrote: Just don't assume that you know better than the creator of the host program when it is okay to bail and how to do so. As the provider of the lower-level abstraction, you guarantee certain

Re: [ft] FT_Done_Face Should Not Return An Error

On Sun, 6 May 2018 00:11:12 +0200, Gregor Mückl wrote: > Just don't assume that you know better than the creator of the host > program when it is okay to bail and how to do so. As the provider of the lower-level abstraction, you guarantee certain invariants. In this case, that every FT_Face has

Re: [ft] FT_Done_Face Should Not Return An Error

On Sat, 05 May 2018 20:10:43 +0200 (CEST), Werner LEMBERG wrote: > I agree with Gregor: A library should not call `exit' by itself. What else is it supposed to do? Lots of code is already ignoring the result from FT_Done_Face. Exhibit A: HarfBuzz

Re: [ft] FT_Done_Face Should Not Return An Error

On 5/5/2018 11:32 PM, Lawrence D'Oliveiro wrote: On Sat, 5 May 2018 19:49:30 +0200, Gregor Mückl wrote: Please don't create another library that blindly terminates its host program on a whim. s/whim/internal consistency failure/ Which is a whim as far as the caller is concerned, isn't it?

Re: [ft] FT_Done_Face Should Not Return An Error

On Sat, 5 May 2018 19:49:30 +0200, Gregor Mückl wrote: > Please don't create another library that blindly terminates its host > program on a whim. s/whim/internal consistency failure/ > Returning an error really is the right thing to do > here. Just make it clear that this is a bad error.

Re: [ft] FT_Done_Face Should Not Return An Error

On Sat, May 5, 2018 at 11:10 AM, Werner LEMBERG wrote: > > >> It is common for object-disposal routines to never return error > >> statuses. The archetypal example is free(3) > >> . If this is passed a valid > >> pointer, it disposes of the

Re: [ft] FT_Done_Face Should Not Return An Error

>> It is common for object-disposal routines to never return error >> statuses. The archetypal example is free(3) >> . If this is passed a valid >> pointer, it disposes of the object; if it is passed NULL, it >> quietly returns without doing anything. If it is

Re: [ft] FT_Done_Face Should Not Return An Error

On 5/5/2018 11:54 AM, Lawrence D'Oliveiro wrote: It is common for object-disposal routines to never return error statuses. The archetypal example is free(3) . If this is passed a valid pointer, it disposes of the object; if it is passed NULL, it quietly returns