C89 issue to respect :-)

[m4tosm4]

I'm still using Visual Studio 2010 which doesn't like C99 syntax.

GnuCOBOL clones should respect the... law! :-)

Example from your latest code...

...on...

https://github.com/OCamlPro/gnucobol (mlio.c)

cob_field_attr	attr;
cob_field   	edited_field = { .size = len, .data = p, .attr = &attr };

...should be converted to...

cob_field_attr  attr;

/* PATCH BEGIN: Convert C99 to C89 (cob_field) */

/*
typedef struct __cob_field {
    size_t                  size;       // Field size
    unsigned char           *data;      // Pointer to field data
    const cob_field_attr    *attr;      // Pointer to attribute
} cob_field;
*/

//cob_field       edited_field = { .size = len, .data = p, .attr = &attr };
cob_field edited_field = { len, p, &attr };

/* PATCH END */

Just saying! ;-)

:-)

[GitMensch]

For GC4 (gitside branch here) we may drop the C89 rule. For the 3.x versions C89 "+ common posix or win32 extensions" should work.

Note that so far GC3 was expected to compile with VS2005... but I think it is time to drop that (as done in GC4 years ago).
GC3.3 should still compile with VS2008 (this is also run in CI - but with disabled XML2 and json - which is likely the reason you've seen it there).

If I understood your point correctly then you suggest we don't use named attributes but instead positional ones, right? Or is that a forward declaration (headers not included up-front)?

Which places does this apply to exactly?

[m4tosm4]

«Which places does this apply to exactly?» It applies in only one instance in all source code, Simon. mlio.c, line 714 713 cob_field_attr attr; 714 *cob_field edited_field = { .size = len, .data = p, .attr = &attr };* 😶‍🌫️

[m4tosm4]

«If I understood your point correctly then you suggest we don't use named attributes but instead positional ones, right? Or is that a forward declaration (headers not included up-front)?» I'm suggesting... Leave GnuCOBOL 3.3 live as is... ...

…

On Sat, Dec 27, 2025 at 1:14 PM Simon Sobisch ***@***.***> wrote: *GitMensch* left a comment (OCamlPro/gnucobol#265) <#265 (comment)> For GC4 (gitside branch here) we *may* drop the C89 rule. For the 3.x versions that should work. Note that so far GC3 was expected to compile with VS2005... but I think it is time to drop that (as done in GC4 years ago). GC3.3 should still compile with VS2008 (this is also run in CI - but with disabled XML2 and json - which is likely the reason you've seen it there). If I understood your point correctly then you suggest we don't use named attributes but instead positional ones, right? Or is that a forward declaration (headers not included up-front)? Which places does this apply to exactly? — Reply to this email directly, view it on GitHub <#265 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B375OX5ZM65HIJLDBKU3USL4D2A3ZAVCNFSM6AAAAACQCST5RKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMOJTHE3TAMZUGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[m4tosm4]

«For GC4 (gitside branch here) we *may* drop the C89 rule. For the 3.x versions that should work.» You can «kill» GC4 as much as you want, but... (please) ...don't «kill»... GC3... ...like «LibLZMA»... did! 😀

…

On Sat, Dec 27, 2025 at 1:14 PM Simon Sobisch ***@***.***> wrote: *GitMensch* left a comment (OCamlPro/gnucobol#265) <#265 (comment)> For GC4 (gitside branch here) we *may* drop the C89 rule. For the 3.x versions that should work. Note that so far GC3 was expected to compile with VS2005... but I think it is time to drop that (as done in GC4 years ago). GC3.3 should still compile with VS2008 (this is also run in CI - but with disabled XML2 and json - which is likely the reason you've seen it there). If I understood your point correctly then you suggest we don't use named attributes but instead positional ones, right? Or is that a forward declaration (headers not included up-front)? Which places does this apply to exactly? — Reply to this email directly, view it on GitHub <#265 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B375OX5ZM65HIJLDBKU3USL4D2A3ZAVCNFSM6AAAAACQCST5RKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMOJTHE3TAMZUGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[GitMensch]

This will be fixed "soonish". I've already adjusted the Appveyor CI that runs a 2008 build to include cJSON and that shows the same issue (which is the reason it now fails to build for that env). I've fixed that locally (different) and want to check it in along with other commit-backlog parts this month.