[Geany-Devel] Lets move to C99

[Colomban Wendling]

…and now the detailed rant, not in the other mail to stay constructive :)

<rant>

Le 16/08/2013 08:07, Matthew Brush a écrit :
> 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?).

No idea.  BTW, note that even latest GCC don't fully support C99
http://gcc.gnu.org/c99status.html

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

I don't.

> - restricted character set support in <iso646.h> (originally specifed in
> AMD1)

WTF.

> - wide-character library support in <wchar.h> and <wctype.h> (originally
> specifed in AMD1)

only Windows actually uses this, and G* uses char* holding UTF-8 bytes,
no point for us.

> - restricted pointers

which are a trick to help the compiler, and that we probably wouldn't
use anyway.

> - variable-length arrays

That's partially useful, yet not terribly missing for me.

> - fexible array members

Err.  IIRC most compilers don't like that, and that's the single most
prominent reason why they don't claim to support C99 (may be wrong, I
can't trust my memory :-').

Ah, and BTW we don't want to use that anyway :)

> - complex (and imaginary) support in <complex.h>
> - type-generic math macros in <tgmath.h>
> - the long long int type and library functions

Very useful for a test editor :)

> - increased translation limits

Cool.

> - remove implicit int

Just don't use it.

> - the vscanf family of functions

We don't need those I'd say, and G* propose them anyway.

> - reliable integer division

What does this mean?

> - universal character names
> - extended identifers

?

> - binary foating-point literals and printf/scanf conversion specifers

Fun.

> - compound literals

That's real fun, I must admit.

> - designated initializers

We used to use those for arrays, but I never saw much point in them.
For structure though they are nice.

> - // comments

Fun.

> - extended integer types in <inttypes.h> and <stdint.h>

Cool.

> - remove implicit function declaration

Just don't use that.

> - preprocessor arithmetic done in intmax_t/uintmax_t

Cool.

> - mixed declarations and code

NOOOOOOOOOOOOOOOOOOOOOOOO!

> - integer constant type rules
> - integer promotion rules

What did change?

> - vararg macros

Those are fun, but still broken IIRC (e.g. usage has limitation, like
requires some arg, I don't remember the details)

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

Fun.

> - trailing comma allowed in enum declaration

Fun, would remove 1 character change in some commits, not that useful.

> - %lf conversion specifer allowed in printf

Fun.

> - inline functions

Those are nice, but I think G* provide them if available, and the
compilers generally are clever enough to inline some anyway.

> - the snprintf family of functions

g*

> - boolean type in <stdbool.h>

what a new thing.  gboolean is fine, isn't it?

> - idempotent type qualifers

Err.

> - empty macro arguments

Fun.

> - new struct type compatibility rules (tag compatibility)

Cool, but we probably don't need it either.

> - _Prama preprocessing operator

Isn't this _Pragma?  Anyway, no.

> - standard pragmas

Err

> - __func__ predefned identifer

Cool, but G_STRFUNC is better because it uses better compilers
extensions if available.

> - VA_COPY macro

Yeah, that's practical in some cases, I must admit :)

> - additional strftime conversion specifers

Cool.

> - LIA compatibility annex

Cool.

> - deprecate ungetc at the beginning of a binary file

Yeah, whatever

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

But I hope you don't suggest to use it :)

> [...]


</rant>