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