I do not think that code duplication is a good idea. I'd better search
common code for designated initializer list and rework it (remove) to get
back C89 style.

Best regards,
Petro

On Sat, Jan 8, 2022, 3:54 PM Alin Jerpelea <jerpe...@gmail.com> wrote:

> that code duplication is the way I was thinking if we want to be able to
> use both compilers and keep all platforms
> Best Regards
> Alin
>
> On Sat, 8 Jan 2022, 14:42 Alan Carvalho de Assis, <acas...@gmail.com>
> wrote:
>
> > Hi Alin,
> >
> > using a menu option in this case will not work because the point is
> > not passing a std c99 flag to the compiler, but using some C99
> > features in the source code to simplify it.
> >
> > For example: the designated initializer list:
> >
> > struct test_s test =
> >   {
> >         .second = 2,
> >         .first =  1
> >   };
> >
> > It is not supported by C89 and adding an entry in the menuconfig will
> > require duplication in the source code to support both standards (C89
> > and C99).
> >
> > BR,
> >
> > Alan
> >
> > On 1/8/22, Alin Jerpelea <jerpe...@gmail.com> wrote:
> > > In my opinion we should try to keep all platforms and avoid breaking
> them
> > > by adopting new standards
> > >
> > > An option would be to add the C99 as a menu option while keeping the
> > > current compilers compatibility
> > >
> > > Best Regards
> > > Alin
> > >
> > >
> > > On Sat, 8 Jan 2022, 13:53 Gregory Nutt, <spudan...@gmail.com> wrote:
> > >
> > >> z80 holds all 8-bit ZiLOG architectures.  That means
> > >>
> > >> z80 using the SDCC compiler
> > >> z180 using the SDCC compiler
> > >> ez80 which normally uses the ZiLOG compiler, but there is an
> > experimental
> > >> version of GCC for the ez80
> > >>
> > >> z16 uses only ZiLOG compiler
> > >>
> > >> Also consider SH1
> > >>
> > >> This will also require changes to INVIOLABLES.md and the coding
> > standard.
> > >> I would also recommend a formal vote to assure that you are following
> > the
> > >> will of the user base and not a personal agenda.  There used to be a
> > >> small
> > >> but important group of retro computer folk using NuttX; this
> eliminates
> > >> support for them. There is language in the INVIOLABLES that is there
> > >> specifically to protect them from actions like this.
> > >>
> > >> I have not heard of anyone using these architectures recently.  I
> would
> > >> say
> > >> that only ez80 is active with active development boards.  There are
> > >> occasional developments with z180-like hardware.
> > >>
> > >> On Fri, Jan 7, 2022 at 11:40 PM Xiang Xiao <xiaoxiang781...@gmail.com
> >
> > >> wrote:
> > >>
> > >> > Ceva we just added this week also supports C99, so we just need to
> > >> > check
> > >> > avr, misoc, or1k, z16 and z80.
> > >> >
> > >> > On Sat, Jan 8, 2022 at 1:35 PM Petro Karashchenko <
> > >> > petro.karashche...@gmail.com> wrote:
> > >> >
> > >> > > In addition I just checked latest GCC with HC12 support is 3.0.4
> > >> version.
> > >> > > It have C99 integrated. Will check with AVR32, but will probably
> > need
> > >> > some
> > >> > > help with others.
> > >> > >
> > >> > > Best regards,
> > >> > > Petro
> > >> > >
> > >> > > On Sat, Jan 8, 2022, 7:15 AM Petro Karashchenko <
> > >> > > petro.karashche...@gmail.com> wrote:
> > >> > >
> > >> > > > Hi,
> > >> > > >
> > >> > > > What about inline functions? Those are also a part on C99.
> > >> > > >
> > >> > > > Are those old architectures checked by the CI? I mean do we
> have a
> > >> > proof
> > >> > > > that those are still compilable with the latest release?
> > >> > > >
> > >> > > > Best regards,
> > >> > > > Petro
> > >> > > >
> > >> > > > On Sat, Jan 8, 2022, 6:37 AM Xiang Xiao <
> > xiaoxiang781...@gmail.com>
> > >> > > wrote:
> > >> > > >
> > >> > > >>
> > >> > > >>
> > >> > > >> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko <
> > >> > > >> petro.karashche...@gmail.com> wrote:
> > >> > > >>
> > >> > > >>> Hello team,
> > >> > > >>>
> > >> > > >>> Recently I mr. @Xiang Xiao <xiaoxiang781...@gmail.com> had a
> > >> > > discussion
> > >> > > >>> in one of the PR's related to C89 code compliance.
> Particularly
> > >> > > related to
> > >> > > >>> initializing a structure by field names (designated
> > >> > > >>> initializers).
> > >> > Mr.
> > >> > > @Xiang
> > >> > > >>> Xiao <xiaoxiang781...@gmail.com> pointed out that "for the
> > common
> > >> > code
> > >> > > >>> it is better to avoid C99 only features".
> > >> > > >>> I examined the current NuttX code and see that currently
> common
> > >> code
> > >> > is
> > >> > > >>> far away from C89 already and things like "<stdbool.h>",
> > >> > > "<inttypes.h>",
> > >> > > >>> "snprintf", "designated initializers", "__VA_ARGS__" (variadic
> > >> macro)
> > >> > > are
> > >> > > >>> deeply embedded into the code.
> > >> > > >>>
> > >> > > >>>
> > >> > > >> We need separate the features that come from the compiler and
> the
> > >> > > >> standard library. Since the libc is provided by NuttX self:
> > >> > > >>
> > >> > > >>    1. The header files(e.g.stdbool.h, intttyes.h) and
> > >> > > >> function(e.g.
> > >> > > >>    snprintf) can be used in common code since NuttX can provide
> > >> > > >> the
> > >> > > >>    implementation for all arch even the arch use a very old
> > >> > > >> compiler
> > >> > > >>    2. The preprocessor (e.g.  __VA_ARGS__) or language(
> > designated
> > >> > > >>    initializers) feature need to avoid or incorporate into the
> > >> > > conditional
> > >> > > >>    macro
> > >> > > >>
> > >> > > >> .
> > >> > > >>
> > >> > > >>> I would like to come up with the suggestion to make C99 as a
> > >> > > >>> prerequisite for the compiler that is used to build NuttX
> code.
> > >> > > >>>
> > >> > > >>
> > >> > > >> As Greg said, if compilers used on all arch supported by NuttX
> > >> support
> > >> > > >> C99, there is no reason to limit us to C89. The compiler status
> > is
> > >> > > >> a
> > >> > > >> keypoint.
> > >> > > >>
> > >> > > >>
> > >> > > >>>
> > >> > > >>> Best regards,
> > >> > > >>> Petro
> > >> > > >>>
> > >> > > >>>
> > >> > >
> > >> >
> > >>
> > >
> >
>

Reply via email to