[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gperf] unsigned long vs. unsigned int
From: |
Bruno Haible |
Subject: |
Re: [bug-gperf] unsigned long vs. unsigned int |
Date: |
Thu, 05 Sep 2019 02:32:23 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-159-generic; KDE/5.18.0; x86_64; ; ) |
Sei Lisa wrote:
> Is compatibility with C standards < C99 an issue?
>
> C99 introduces uint_fast32_t via stdint.h, which would be perfect for the
> task. It's not an optional type like uint32_t and others, it's mandatory.
It would be a good idea to use uint_fast32_t, if we could rely on it
everywhere.
But indeed, you hit the nail on the head: uint_fast32_t is not portable
enough [1], and gperf generated code should be usable without requiring
Autoconf macros - otherwise gperf makes the developer's life harder.
> Anyway, instead of a gperf option, it could be an overridable C macro in
> the output, like flex/bison do with YYLTYPE and similar.
This too would make the use of gperf harder.
Bruno
[1] https://www.gnu.org/software/gnulib/manual/html_node/stdint_002eh.html
- [bug-gperf] One usability and 4 fine tuning performance suggestions (cache lines and array size), Mark Stankus, 2019/09/04
- Re: [bug-gperf] gperf as a library, Bruno Haible, 2019/09/04
- Re: [bug-gperf] unsigned long vs. unsigned int, Bruno Haible, 2019/09/04
- Re: [bug-gperf] large lengths, Bruno Haible, 2019/09/04
- Re: [bug-gperf] shrinking the asso_values array, Bruno Haible, 2019/09/04
- Re: [bug-gperf] bit packing tricks, Bruno Haible, 2019/09/04