>> OK. What about passing `__LINE__` then?
>
> Alright, I have done the relevant changes, to pass
> line through a function parameter I had to change
> `FT_DEBUG_INNER' and `FT_ASSIGNP_INNER'
> macros like this:
> ```
> #define FT_DEBUG_INNER( exp ) ( _ft_debug_file = __FILE__, \
>
> OK. What about passing `__LINE__` then?
Alright, I have done the relevant changes, to pass
line through a function parameter I had to change
`FT_DEBUG_INNER' and `FT_ASSIGNP_INNER'
macros like this:
```
#define FT_DEBUG_INNER( exp ) ( _ft_debug_file = __FILE__, \
>> Having two versions would also allow to use a function internally
>> so that you can (a) avoid the `do {} while (0)` construction, and
>> (b) still use the macro within a conditional.
>
> I thought about that, but if we create a function then the memory
> dump won't print the actual line
> There should be zero overhead for the non-debugging case.
> Having two versions would also allow to use a function internally so
> that you can (a) avoid the `do {} while (0)` construction, and (b)
> still use the macro within a conditional.
I thought about that, but if we create a function
> How is this:
> https://lists.nongnu.org/archive/html/freetype-commit/2020-07/msg00067.html
> ?
Nice! However, I think it's better to have two versions of
`SFD_ALLOC` and `SFD_FREE` depending on whether debugging is enabled
or not. There should be zero overhead for the non-debugging case.
Hello Werner, How is this: https://lists.nongnu.org/archive/html/freetype-commit/2020-07/msg00067.html ? Sent from Mail for Windows 10
