In general I don't see any point in keeping compatibility with a standard as old as C89, what target (that we support) still needs that?

The items that are obviously likely to be useful to Geany I have marked in the list with **. Some of these may come with magic options to gcc, but that limits us to that compiler.

The more we can allow modern(ish :) programming styles using a well known standard the simpler it is to produce correct code (eg inlines not macros, who will remember that EMPTY may compute its arguments multiple times).

At the moment C11 is too new (not enough complete support) but C99 is fine.

Unless we follow the example of gcc itself and upgrade to C++ :)

On 16 August 2013 16:07, Matthew Brush <mbrush@codebrainz.ca> wrote:

Hi,

Up till now we've tried to stay compatible with ANSI C89 because of GTK+-stack doing so (unless I missed the real reason?).

I propose we update to allowing C99 for the following reasons:

- restricted character set support in <iso646.h> (originally specifed in AMD1)
- wide-character library support in <wchar.h> and <wctype.h> (originally specifed in AMD1)
** - restricted pointers
** - variable-length arrays
** - flexible array members
- complex (and imaginary) support in <complex.h>
- type-generic math macros in <tgmath.h>
- the long long int type and library functions
- increased translation limits
- remove implicit int
** - the vscanf family of functions
** - reliable integer division
- universal character names
- extended identifers
- binary foating-point literals and printf/scanf conversion specifers
- compound literals
** - designated initializers
** - // comments
** - extended integer types in <inttypes.h> and <stdint.h>
** - remove implicit function declaration
** - preprocessor arithmetic done in intmax_t/uintmax_t
** - mixed declarations and code
** - integer constant type rules
- integer promotion rules
- vararg macros
- additional math library functions in <math.h>
- foating-point environment access in <fenv.h>
- IEC 60559 (also known as IEC 559 or IEEE arithmetic) support
- trailing comma allowed in enum declaration
- %lf conversion specifer allowed in printf
** - inline functions
** - the snprintf family of functions
** - boolean type in <stdbool.h>
- idempotent type qualifers
- empty macro arguments
** - new struct type compatibility rules (tag compatibility)
- _Prama preprocessing operator
- standard pragmas
- __func__ predefned identifer
- VA_COPY macro
- additional strftime conversion specifers
- LIA compatibility annex
- deprecate ungetc at the beginning of a binary file
- remove deprecation of aliased array parameters

(Source: list is 2nd hand from http://www.open-std.org/JTC1/sc22/wg14/www/docs/n869/)

And that's just improvements since 1999 (way back when I was in high school), not to mention more recent changes in the latest C11 standard.

I think for us the most likely consequences are:

- Coding in the new millennium style :)
- Microsoft Visual C++ compiler is not C99 conformant and plans not to ever be AFAIK (of little consequence since we don't compile with MSVC).
- Allowed to use // style comments
- Allowed to declare loop counter-style variable inside the for loop.
- Use standard C instead of G*-portability wrappers in various place (bool, fixed-width ints, etc.).

This is just sort of random, but I feel that some our code could be better if we depended less on G*-stack and more on (>10 year old) ISO standards.

P.S. Sorry for the bikeshed bait.

Red and purple.

Cheers

Lex

Cheers,
Matthew Brush
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel