Re: [ft] FT_Done_Face Should Not Return An Error

[Werner LEMBERG]

>>> * 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 if you suggest to *always* return FT_Err_Ok.  I suggest
that the function returns the various error codes it already returns,
for backward compatibility.

For me, FT_Done_Face is just a wrapper around `free'.  If you want
finer control for whatever reasons, simply replace `free' with a
custom deallocator.


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

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 code can continue to do so.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[suzuki toshiya]

> 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 compatibility, without sufficient rationale and
concrete evaluation of the impact.

On 5/11/2018 7:21 AM, Lawrence D'Oliveiro wrote:

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


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.

Could you please clarify what you mean? Otherwise it’s going to be very
difficult conducting a coherent conversation with you.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype




___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

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

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.

Could you please clarify what you mean? Otherwise it’s going to be very
difficult conducting a coherent conversation with you.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Gregor Mückl]

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 for this discussion. Why do you want this change at all?


___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Werner LEMBERG]

>> 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 FT_List_Find call returns NULL?
>   I think it should print a message to stderr and abort the program.

I don't want that.  I still think that a library should return control
to the caller even if something weird is happening.  Just imagine a
Windows program where output to stderr is not displayed.  You rather
have to give control back to Windows so that it can create a useful
dialogue window.

> Ignoring the internal consistency failure is not really a good idea.
> It is very likely an indication that memory blocks are screwed.  So
> if the code just tries to keep going, it could hit a segfault later
> on, or otherwise behave unpredictably.

Why do you think, from a user's point of view, that aborting is better
than segfaulting?  In both cases the point of failure is not where the
error gets triggered.  Only a tool like `valgrind' can give more
information to find out where the memory got corrupted.

> And then the programmer is left scratching their head as to what
> went wrong.  By reporting the problem as close as possible to the
> point of its discovery, you maximize the chance that it can be found
> and fixed.

I don't think so.  If you get a crash, the first action usually is to
run the program within a debugger or a tool like `valgrind' (assuming
you have compiled with activated debugging support).

What I can imagine, however, is to add `assert' statements.  FreeType
has very few of them; maybe there should be more to better check
consistency.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

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 returns NULL?
  I think it should print a message to stderr and abort the program.

Ignoring the internal consistency failure is not really a good idea. It
is very likely an indication that memory blocks are screwed. So if the
code just tries to keep going, it could hit a segfault later on, or
otherwise behave unpredictably. And then the programmer is left
scratching their head as to what went wrong. By reporting the problem
as close as possible to the point of its discovery, you maximize the
chance that it can be found and fixed.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Werner LEMBERG]

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

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

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?

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Werner LEMBERG]

>> 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.
> 
> You mean, the caller is expected to call FT_New_Face, then pass
> ownership of the object to the intermediate layer, which then makes
> use of it and has the responsibility of calling FT_Done_Face?

No.  The user plug-in is expected to call `FT_New_Face' and other
FreeType stuff, but the deallocation is done by the core application,
let's say, by a hypothetical `clean_up_user_module' function.  Again,
this is a hypothetical, bad example.  No need actually to discuss this
further :-)


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

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 that the user module always does the right
> thing.

You mean, the caller is expected to call FT_New_Face, then pass
ownership of the object to the intermediate layer, which then makes use
of it and has the responsibility of calling FT_Done_Face?

If the intermediate layer is not expecting a NULL pointer, then an
error on FT_Done_Face would seem to be the least of your problems.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

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 source”?

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Werner LEMBERG]

>> 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' can't handle value NULL but the fact
>> that it has received such a handle, which indicates a problem in
>> the calling program.
> 
> NULL should be perfectly valid -- it simply indicates the object was
> never allocated.

Well, yes – if you trust the source.  As mentioned, this is a
hyphothetical example.

Anyway, I won't change FreeType's behaviour.  It will continue to
return an error code if `NULL' is passed as an `FT_Face' object, and
you are free to completely ignore the return value :-)

Maybe the documentation can be improved; I'm open to all suggestions.


   Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

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 this should be reported back – not because
> `FT_Done_Face' can't handle value NULL but the fact that it has
> received such a handle, which indicates a problem in the calling
> program.

NULL should be perfectly valid -- it simply indicates the object
was never allocated.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

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
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[suzuki toshiya]

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 functions.
something like a registration mechanism of a function pointer to be called when 
FT_Done_Face or FT_Done_Library is going to return some error.
how to do that?",
the discussion could be more constructive.


Some desktop applications on Unix systems are expected to be running from the 
user's login to the user's logout. Some of them are depending FreeType. Thus, 
making FreeType abort immediately by a bad font, it can make some environment 
quite inconvenient.

# I remember, Mac OS X 10.0 had such problem. A bad font in user's font 
directory can prevent the login itself. It was quite inconvenient, except of 
the people knowing SSH or CUI login method.

On 5/7/2018 1:55 PM, Werner LEMBERG wrote:
> 
>>> I agree with Gregor: A library should not call `exit' by itself.
>>
>> What else is it supposed to do?
> 
> Nothing.
> 
>> Lots of code is already ignoring the result from FT_Done_Face.
> 
> Yes.  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.
> 
> 
>  Werner
> 
> ___
> Freetype mailing list
> Freetype@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype
> 


___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Werner LEMBERG]

>> 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' 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' can't handle value NULL but the fact that it has
received such a handle, which indicates a problem in the calling
program.

For all other cases `FT_Done_Face' can't do any additional harm, so
you can safely ignore its return value (similar to `free').


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

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 “potentially happen” -- that’s why I asked.

Your wonderfully elaborate and complicated, not to say fragile,
error-recovery system cannot cope with it, can it?

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

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?

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

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 called. That
>>> way, RAII patterns in my code get executed: resources are freed,
>>> files are closed (writing buffered file contents to disk) etc.  
>
>> What happens if you have another FT_Face to dispose of?  
> 
> Why would that matter? I cannot see the relevance to the topic.

In the process of recovering from the error in disposing of the first
one, do you try to dispose of the second one?

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Gregor Mückl]

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 of the
program. And its asFormattedText method turns it into a readable
string. In various cases, I have dumped this string onto the console
(as in the example above), shown this in a Windows message box (no
console there) and written it into a log file that a user can locate
in the file system and send to me.

Also, on the way up to the exception handler in main(), stack
unwinding causes destructors of various objects to be called. That
way, RAII patterns in my code get executed: resources are freed,
files are closed (writing buffered file contents to disk) etc.


What happens if you have another FT_Face to dispose of?


Why would that matter? I cannot see the relevance to the topic.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

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 method turns it into a readable
> string. In various cases, I have dumped this string onto the console
> (as in the example above), shown this in a Windows message box (no
> console there) and written it into a log file that a user can locate
> in the file system and send to me.
> 
> Also, on the way up to the exception handler in main(), stack
> unwinding causes destructors of various objects to be called. That
> way, RAII patterns in my code get executed: resources are freed,
> files are closed (writing buffered file contents to disk) etc.

What happens if you have another FT_Face to dispose of?

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Gregor Mückl]

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.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

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

[Gregor Mückl]

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
invariants. In this case, that every FT_Face has a driver, and the
driver has knowledge of that FT_Face as long as it exists.

If that invariant breaks, there’s nothing that the caller can
reasonably do about it, because it’s none of the caller’s business.



This is where you reasoning is wrong. The abstraction is that the caller 
does not need to understand the exact nature of the error.


Error handling code rarely concerns itself with the exact error that 
happened, because they typically lead to the same handling strategies in 
the caller anyway. FT_Done_Face is also on this category.


(the only class of functions that I can think of that requires the 
caller to differentiate between error codes are a few blocking system 
calls that suffer from occasional spurious wake ups).



That’s what “abstraction” means.


This is highly dependent on the actual purpose of the program ...


In that case, perhaps you could show us an example or two of how you
deal with error returns from FT_Done_Face?



There are two choices here:

1. ignore it


From actual code that I wrote about 6 years ago:
-
	// Freetype could return an error code here, but it's not particularly 
useful to respect it

FT_Done_Face(TL_Globals.fonts[font].face);
-

Strictly speaking, this code is wrong, but this was for a game engine, 
so the worst thing that can happen is the player getting angry at a 
crashing game.


2. propagate the error up
=

Example using some C++ library code of mine:

-
if(FT_Done_Face(face != 0) {
throw gltb::Error("Freeing Freetype font failed", 
"TL_UnloadFont()");
}
-

In my main() functions there always is the following corresponding code 
around everything:


-
int main(int argc, char *argv[]) {
try {
// actual program code
} catch(gltb::Exception ) {
std::cerr << e.asFormattedText() << std::endl;
return 1;
}
return 0;
}
-

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 method turns it into a readable string. In various 
cases, I have dumped this string onto the console (as in the example 
above), shown this in a Windows message box (no console there) and 
written it into a log file that a user can locate in the file system and 
send to me.


Also, on the way up to the exception handler in main(), stack unwinding 
causes destructors of various objects to be called. That way, RAII 
patterns in my code get executed: resources are freed, files are closed 
(writing buffered file contents to disk) etc.


This would not work if you just blindly call exit() or abort().

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

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 a driver, and the
driver has knowledge of that FT_Face as long as it exists.

If that invariant breaks, there’s nothing that the caller can
reasonably do about it, because it’s none of the caller’s business.

That’s what “abstraction” means.

> This is highly dependent on the actual purpose of the program ...

In that case, perhaps you could show us an example or two of how you
deal with error returns from FT_Done_Face?

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

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
:

static void
_hb_ft_face_destroy (FT_Face ft_face)
{
  FT_Done_Face (ft_face);
}

Exhibit B: Fontconfig
, which
also ignoring the result from FC_Done_FreeType:

static FcBool
FcFileScanFontConfig (FcFontSet *set,
  FcBlanks  *blanks,
  const FcChar8 *file,
  FcConfig  *config)
{
...
FT_Done_Face (face);
...

FT_Done_FreeType (ftLibrary);

return ret;
}

Another pair of examples from Fontconfig
:

FcPattern *
FcFreeTypeQuery(const FcChar8   *file,
int id,
FcBlanks*blanks,
int *count)
{
...

FT_Done_Face (face);
bail:
FT_Done_FreeType (ftLibrary);
return pat;
}

Exhibit C: libraqm
 (one of
3 instances):

static void
_raqm_free_text_info (raqm_t *rq)
{
  if (!rq->text_info)
return;

  for (size_t i = 0; i < rq->text_len; i++)
  {
if (rq->text_info[i].ftface)
  FT_Done_Face (rq->text_info[i].ftface);
  }

  free (rq->text_info);
  rq->text_info = NULL;
}

Is all this code wrong?

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Gregor Mückl]

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?


Returning an error really is the right thing to do
here. Just make it clear that this is a bad error.


And what exactly is the caller supposed to do about it?



Whatever the hell it pleases to do. I've outlined a few possibilities 
already. Depending on what the program is for, it may need to do some 
things even if (or especially because) things went wrong.


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. This is highly 
dependent on the actual purpose of the program - which you can't assume 
anything about. It could be a database frontend, a game or a medical device.


The only thing that I could possibly see myself agreeing with is a set 
of asserts that can be compiled in conditionally in specialized debug 
builds. So you'd get to break into the debugger if one of these very bad 
situations happen. A release build should be more optimistic and try to 
keep running instead, reporting the error.


___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

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.

And what exactly is the caller supposed to do about it?

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[J Decker]

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 object; if it is passed NULL, it
> >> quietly returns without doing anything.  If it is passed an invalid
> >> pointer, then this indicates a program bug, so there is no point
> >> returning an error code anyway: better to report an error message
> >> to stderr and even abort the program.
>
> I agree with Gregor: A library should not call `exit' by itself.
>

REALLY wish someone could convince libpng of that.


>
> >> [...]  Otherwise, if it is passed NULL, it should just quietly
> >> return without doing anything.  This makes it easier to write code
> >> that initializes all temporary pointers up front and
> >> unconditionally disposes them at the end; there is no need to
> >> tediously check everything for NULL pointers, because the disposal
> >> routines will take care of that.
>
> It's not clear to me how such a situation can arise with FreeType.
> Please give an example.
>
>
> Werner
>
> ___
> Freetype mailing list
> Freetype@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype
>
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Werner LEMBERG]

>> 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 passed an invalid
>> pointer, then this indicates a program bug, so there is no point
>> returning an error code anyway: better to report an error message
>> to stderr and even abort the program.

I agree with Gregor: A library should not call `exit' by itself.

>> [...]  Otherwise, if it is passed NULL, it should just quietly
>> return without doing anything.  This makes it easier to write code
>> that initializes all temporary pointers up front and
>> unconditionally disposes them at the end; there is no need to
>> tediously check everything for NULL pointers, because the disposal
>> routines will take care of that.

It's not clear to me how such a situation can arise with FreeType.
Please give an example.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FT_Done_Face Should Not Return An Error

[Gregor Mückl]

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
without doing anything. If it is passed an invalid pointer, then this
indicates a program bug, so there is no point returning an error code
anyway: better to report an error message to stderr and even abort the
program.

Looking at the code for FT_Done_Face, from src/base/ftobjs.c:

   FT_EXPORT_DEF( FT_Error )
   FT_Done_Face( FT_Face  face )
   {
 FT_Error error;
 FT_Driverdriver;
 FT_Memorymemory;
 FT_ListNode  node;


 error = FT_ERR( Invalid_Face_Handle );
 if ( face && face->driver )
 {
   face->internal->refcount--;
   if ( face->internal->refcount > 0 )
 error = FT_Err_Ok;
   else
   {
 driver = face->driver;
 memory = driver->root.memory;

 /* find face in driver's list */
 node = FT_List_Find( >faces_list, face );
 if ( node )
 {
   /* remove face object from the driver's list */
   FT_List_Remove( >faces_list, node );
   FT_FREE( node );

   /* now destroy the object proper */
   destroy_face( memory, face, driver );
   error = FT_Err_Ok;
 }
   }
 }

 return error;
   }

the only thing that can really go wrong is if the face cannot be
found among the driver’s memory blocks. Clearly something has gone
catastrophically wrong in this case, so it makes sense to report an
error and abort the program.

Otherwise, if it is passed NULL, it should just quietly return without
doing anything. This makes it easier to write code that initializes all
temporary pointers up front and unconditionally disposes them at the
end; there is no need to tediously check everything for NULL pointers,
because the disposal routines will take care of that.


Please don't create another library that blindly terminates its host 
program on a whim. Returning an error really is the right thing to do 
here. Just make it clear that this is a bad error.


Calling exit() uncontrollably on an error in a library is bad for a 
whole list of reasons, including but not limited to:


- robs host program of any chance to do a sane cleanup and graceful exit
- prevents the generation of an error report in programs that have this 
QA feature
- circumvents cleanup and error handling mechanisms of other programming 
languages (e.g. C++ stack unwinding)


Regards,
Gregor


___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype