[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libextractor - key-value pairs and mime types

From: Christian Grothoff
Subject: Re: libextractor - key-value pairs and mime types
Date: Tue, 8 Feb 2022 23:15:08 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

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


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]