rking
existing code to be C89, we should reevaluate the C89 requirement.
C99 and C11 have added a lot of language features, and by updating the C
standard to a newer version, we will add more tools to the NuttX toolbox.
Thanks,
Alan
However, there is code in the
> codebase today that is not C89 compliant. Rather than reworking
> existing code to be C89, we should reevaluate the C89 requirement.
>
> C99 and C11 have added a lot of language features, and by updating the C
> standard to a newer version, we will add mo
gt;
> > I'll summarize my thoughts here.
> >
> > Currently NuttX has a C89 requirement. However, there is code in the
> > codebase today that is not C89 compliant. Rather than reworking
> > existing code to be C89, we should reevaluate the C89 requirement.
> &
tly posted an issue to the NuttX Github page:
> > > https://github.com/apache/incubator-nuttx/issues/6896
> > >
> > > I'll summarize my thoughts here.
> > >
> > > Currently NuttX has a C89 requirement. However, there is code in the
> > > codebas
Hi,
That would be -1 for me too.
Reason 1 from Nathan could change my vote.
But reason 2 would be a shame. We have one of the few a RTOS that
support CPUs outside ARM.
TBH, there is no solid technical reason to change this rule. Most of the
things mentioned in this comment are syntactic su
-1 for the same reasons
On Tue, 30 Aug 2022, 11:30 Sebastien Lorquet, wrote:
> Hi,
>
> That would be -1 for me too.
>
> Reason 1 from Nathan could change my vote.
>
> But reason 2 would be a shame. We have one of the few a RTOS that
> support CPUs outside ARM.
>
>
> TBH, there is no solid techni
On Tue, Aug 30, 2022 at 5:30 PM Sebastien Lorquet
wrote:
> Hi,
>
> That would be -1 for me too.
>
> Reason 1 from Nathan could change my vote.
>
> But reason 2 would be a shame. We have one of the few a RTOS that
> support CPUs outside ARM.
>
>
> TBH, there is no solid technical reason to change
e.
> > > >
> > > > Currently NuttX has a C89 requirement. However, there is code in the
> > > > codebase today that is not C89 compliant. Rather than reworking
> > > > existing code to be C89, we should reevaluate the C89 requirement.
> > > &
recently posted an issue to the NuttX Github page:
> > > > > https://github.com/apache/incubator-nuttx/issues/6896
> > > > >
> > > > > I'll summarize my thoughts here.
> > > > >
> > > > > Currently NuttX has a C89 requ
On Mon, Aug 29, 2022 at 7:54 PM Alan Rosenthal
wrote:
> Hi!
>
> What needs to be done to open the discussion to consider changing the
> rules?
>
> Also please see a very detailed comment on the github issue here by
> @robertlipe:
> https://github.com/apache/incubator-nuttx/issues/6896#issuecommen
On Tue, Aug 30, 2022 at 3:18 AM Nathan Hartman wrote:
> Just my thoughts... I'll be glad to hear the thoughts of others.
I can understand both sides.. and that this is quite a large
architectural change that would impact both compatibility and
workload.. maybe a clear list of pros (+1) and cons (-
> Just FYI, based on what Byron points out with regard to the Zilog
families needing C89 (and possibly other archs that weren't mentioned), I
would probably vote -1 unless...
There have been several other cases over the years where there were ports
to classic architectures no longer supported by c
On Tue, Aug 30, 2022 at 10:43 PM Gregory Nutt wrote:
> > Just FYI, based on what Byron points out with regard to the Zilog
> families needing C89 (and possibly other archs that weren't mentioned), I
> would probably vote -1 unless...
>
> There have been several other cases over the years where th
Yes. 2.95
> > Classic Z80 is probably not viable due to the 64Kb address limitation but
> > is still relevant for Z80 derived parts with MMUs such as Z180 and the ZX
> > Spectrum Next or with wider address buses such as the eZ80. z8 was never
> > well tested. But eZ80 and ZNEO have been importa
On Wed, Aug 31, 2022 at 3:39 AM Gregory Nutt wrote:
> Yes. 2.95
>
>
> > > Classic Z80 is probably not viable due to the 64Kb address limitation
> but
> > > is still relevant for Z80 derived parts with MMUs such as Z180 and the
> ZX
> > > Spectrum Next or with wider address buses such as the eZ80.
Since SDCC supports Zilog chipset very well, why not switch from ZDS-II to
> SDCC?
>
SDCC supports z80 and z180 but none of the other ZiLOG chipsets. ez80 has
an unverified GCC port but ZDS-II is the only compiler option for the
remaining parts.
See http://sdcc.sourceforge.net/
> > compiler.h
On Tue, Aug 30, 2022 at 4:16 PM Gregory Nutt wrote:
> > > compiler.h has changed a lot. Does it still support compilers without
> > > inline support? It appears not. I used to define inline to be nothing
> > for
> > > ZDS-II which worked okay except for static inline functions in header
> > fil
On Tue, Aug 30, 2022 at 10:45 AM Gregory Nutt wrote:
> z8, ez80, and ZNEO using the ZiLOG ZDS-II compiler. I don't know the
> current outstanding issues with that compiler. The Z80 parts currently use
> SDCC but could also use one of several other open source compilers
> such as Z88dk
> which I
> There used to be one defining inline to be nothing for ZDS-II . It would
> > only be necessary to restore it for ZDS-II. This does not fix the
> function
> > duplication of static inline functions in header files, however.
>
> Is the duplication really a problem, though?
>
> After all, the whole
On Wed, Aug 31, 2022 at 11:06 AM Gregory Nutt wrote:
>
> > There used to be one defining inline to be nothing for ZDS-II . It would
> > > only be necessary to restore it for ZDS-II. This does not fix the
> > function
> > > duplication of static inline functions in header files, however.
> >
> > I
20 matches
Mail list logo
