Re: libextractor - key-value pairs and mime types

[Christian Grothoff]

I've added your patch and also clarified the use-case for RESERVED
(which is still different from your proposed 'NONE'). Anyway, for
further discussions on this, please use the libextractor list...

-Christian

On 2/8/22 7:21 PM, madmurphy wrote:
> Actually, the first thing that I thought when I read
> |EXTRACTOR_METATYPE_RESERVED| was “not used today, but tomorrow will be
> used for the book's cover” :)
> 
> It definitely needs a renaming!
> 
> --madmurphy
> 
> 
> On Tue, Feb 8, 2022 at 5:52 PM madmurphy <madmurphy333@gmail.com
> <mailto:madmurphy333@gmail.com>> wrote:
> 
>     Of course, the value of |EXTRACTOR_METATYPE_RESERVED| would be even
>     better (zero would be the natural value for something like this).
> 
>     But then it's a lexical problem. If I see something marked as
>     “reserved” I read “do not ever try to use this label”.
> 
>     Since already libextractor uses |EXTRACTOR_METATYPE_RESERVED| with
>     the meaning of |EXTRACTOR_METATYPE_NONE|, would it not make sense to
>     rename |EXTRACTOR_METATYPE_RESERVED| to |EXTRACTOR_METATYPE_NONE|
>     and tell the user that there is nothing “reserved” about it?
> 
>     By instinct if I see a label named |EXTRACTOR_METATYPE_RESERVED| I
>     might think that there are cases in which libextractor marks a
>     metatype with |EXTRACTOR_METATYPE_RESERVED|, expecting me to treat
>     is as an opaque label. Instead, |EXTRACTOR_METATYPE_NONE| to be
>     usable requires libextractor never to mark anything publicly with it
>     (or throw it as a return value). Since apparently this is the case,
>     a comment similar to the one I had left in the patch would also be
>     useful (“used by libextractor only internally; available to the user
>     for marking an |enum EXTRACTOR_MetaType| as not carrying any
>     meaningful value”).
> 
>     --madmurphy
>