Front page | perl.perl5.porters |
Postings from May 2021
Re: C99
Thread Previous
|
Thread Next
From:
Karl Williamson
Date:
May 18, 2021 15:45
Subject:
Re: C99
Message ID:
4124f392-65d2-7012-9e49-d20145ba7539@khwilliamson.com
On 5/18/21 6:01 AM, Nicholas Clark wrote:
> What are we trying to achieve:
Some of this was hashed out 6 months ago:
http://nntp.perl.org/group/perl.perl5.porters/258392
Smoke results
http://nntp.perl.org/group/perl.perl5.porters/258488
>
> We want the developer documentation to say what C constructs are fair game
> in non-platform-specific code. This is going to be "you can use all of C89
> plus the following", with an explicit list of useful features we know work.
>
> The C dialect we use is constrained by
>
> * platforms we support where the only compiler is inflexible (eg HP-UX)
> * C++ extensions on CPAN need our headers, hence our headers must also be
> conformat C++
>
> We also can choose to be constrained by supporting older less flexible
> compilers on platforms where newer compilers are available. Hence *this*
> choice of C dialect is intertwined with the "platform" support choices.
>
>
> Where we are now:
>
> C compilers are rarely "C89 and not a penny more". We "cheat" somewhat
> and already use or emulate what we need for:
>
> * bool
> * static inline
> * static assert
>
> We might be able to add this this list without needing any trade off between
> "feature" and "platform support"
>
> Likely gcc 3.1 or later is just fine:
> https://gcc.gnu.org/c99status.html
> It's the other compilers that will be "fun".
>
> Postgres has a coding standard that might be useful:
> https://www.postgresql.org/docs/13/source-conventions.html
> but curiously it says
>
> A few features included in the C99 standard are, at this time, not
> permitted to be used in core PostgreSQL code. This currently includes
> variable length arrays, intermingled declarations and code, // comments,
> universal character names. Reasons for that include portability and
> historical practices.
>
> without listing any more details about why.
>
>
> What we might like:
>
> For each C99 feature we might like, it would be useful to *tabulate*
>
> 1) how using this would improve the code
> 2) what compilers/platforms don't support this directly
> 3) can it be emulated/worked around for them
>
> that way we can make sensible trade-off decisions, and document the "why".
>
> I think that the list is longer than this, and I don't know the
> "hinder"/"work around" parts, but *as a start*
>
> Feature: mixed declarations and code
> Benefit: Can directly reduce line count without reducing readability,
> Can indirectly make it easier to use const
> Hindered by:
> Work around:
>
> Feature: member structure initialisers
> Benefit: Clearer code.
> Less chance of errors.
> Structures can be re-ordered wit out makework.
> Hindered by: frustratingly these were only recently added to C++, so we
> couldn't use them in headers, even if we can use them elsewhere
> Work around:
>
> Feature: 64 bit integer types
> even if slow, and just for arithmetic and bitwise operators
> Benefit: certain calculations can be expressed directly
> Hindered by:
> Work around:
>
> Feature: // comments
> Benefit:
> Hindered by:
> Work around:
>
> Feature: vararg macros
> Benefit:
> Hindered by:
> Work around:
>
Thread Previous
|
Thread Next