develooper Front page | perl.perl5.porters | Postings from May 2021

Re: C99

Thread Previous | Thread Next
From:
H.Merijn Brand
Date:
May 18, 2021 13:28
Subject:
Re: C99
Message ID:
20210518152758.20f18634@pc09
On Tue, 18 May 2021 12:01:02 +0000, Nicholas Clark <nick@ccl4.org>
wrote:

> What are we trying to achieve:
> 
> 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)

1. The native AIX xlC compiler is even more restrictive

2. The native compiler on HP-UX is restrictive, but I'd like to note
   that building *recent* GNU gcc is close to impossible on HP-UX. This
   means that using the less restrictive GNU gcc on HP-UX is another
   restriction on itself, as the most recent supported version is max
   something like gcc-4.6.2

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

Some of them are in their default mode, but know/support run-time
options to extend into the C99 domain. As it stands, the hints files
know about those options.

> 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

Increase readability by declaring variables for the scope/block they
are used in

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

	NONE!

> Hindered by: 

	Reduced consistency

> Work around: 

	Don't use it

> ------------ -------------------------------------------------------- 
> Feature:     vararg macros
> Benefit:     
> Hindered by: 
> Work around: 


-- 
H.Merijn Brand  https://tux.nl   Perl Monger   http://amsterdam.pm.org/
using perl5.00307 .. 5.33        porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
                           

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About