bug-gperf
[Top][All Lists]
Advanced

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

Re: [bug-gperf] modernizing


From: Bruno Haible
Subject: Re: [bug-gperf] modernizing
Date: Sun, 20 Dec 2009 11:41:35 +0100
User-agent: KMail/1.9.9

Hi,

Albert Cahalan wrote on 2009-11-09:
> It's 2009, nearly 2010, yet gperf still defaults to pre-historic C.
> There isn't even any reason to support that anymore. Even proprietary
> systems from Sun and HP have ANSI compilers now.

Yes, good point. I'm changing the default language from old-style C to
ANSI-C:

2009-12-20  Bruno Haible  <address@hidden>

        Change the default language to ANSI-C.
        * src/options.cc (Options::long_usage): Mention new default language.
        (Options::Options): Change default of _option_word.
        (Options::set_language): Change fallback.
        * doc/gperf.texi (Gperf Declarations, Output Language): Mention new
        default language.
        * NEWS: Mention the change.
        Reported by Albert Cahalan <address@hidden>.

> The register keyword is way-obsolete ugly cruft. It's not even
> being used in a reasonable way; there aren't enough local variables
> for it to make sense even if modern compilers cared.

On the other hand, compilers don't reject or warn about it. So there is no
harm in keeping the 'register' keyword.

> There should be a way to put arbitrary compiler-specific attributes
> onto the functions. For example, __attribute__((visibility("hidden")))
> __declspec(fastcall), static, or __forceinline could be added.

You can already do so by processing gperf's output through a 'sed' script
that makes the adjustments.

> I particularly want to make in_word_set static.

Likewise. Pipe it through sed -e 's/^\(struct .* \*\)$/static \1/'
and you're done.

> There should be a way to set a global prefix, much like the "yy" used
> for lex and yacc.

There are already options to set all possible identifiers. A global
prefix option would IMO just raise even more questions about which option
has priority over which one. There's nothing you cannot do with the
existing options.

> There should be a way to get linux-kernel style indentation.
> (at minimum: real tabs, opening curly braces not by themselves,
> and the closing curly brace not indented at all)

I would not think that this is an important requirement, because
gperf's output is normally kept in a separate file and never edited
by hand.

But anyway, you can postprocess gperf's output through the GNU 'indent'
program. Does GNU indent support Linux kernel style? If not, feel free
to suggest it to the GNU indent maintainer.

> The requirement that "name" to be first in the struct is trouble.
> For example, it can cause padding when vectors are in use. A nice
> solution is C99 struct initializers.

I don't fully understand what you mean. Can you show an example where
padding is needed when 'name' is the first field in the user type, and
where none is needed otherwise?

> There should be a way to get the restrict keyword on all pointer
> arguments. You could make it an option, or do something like this:
> 
> #if __STDC_VERSION__ >= 199901
> #define gprof_restrict restrict
> #elif _MSC_VER >= 1400
> #define gprof_restrict __restrict
> #elif __GNUC__ > 2 || __GNUC_MINOR__ >= 92
> #define gprof_restrict __restrict__
> #else
> #define gprof_restrict
> #endif

The 'restrict' modifier makes sense only for functions which take at least
2 pointer arguments. This is not the case with the gperf generated functions.

The 'restrict' modifier also makes sense only for function which write
something to memory. This too is not the case with the gperf generated
functions.

But anyway, you can add the 'restrict' modifier yourself through postprocessing
with 'sed'.

Bruno




reply via email to

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