I would consider option 3 to be the worst choice. That could bloat can be
enormous and unacceptable as I have seen in the past. I saw growth by many
kbyte in such cases. Not a good compromise.Sent from Samsung tablet.
-------- Original message --------From: Xiang Xiao <xiaoxiang781...@gmail.com>
Date: 7/29/20 12:54 AM (GMT-06:00) To: dev@nuttx.apache.org Subject: RE: Can
we implement ctype functions through table? The new option just make the
situation worse. The same code works insome configurations, but breaks in other
configurations.Since the standard confirmation is the most important principle
forNuttX, we have three options:1.Implement ctype function with table and add
256 byte to ROM2.Change macro to normal function and lose some
performance3.Change macro to inline function and some old compilers may
generatethe bloat codeall ctype functions are one line code, so option 3 may be
a good compromise.> -----Original Message-----> From: David Sidrane
<david.sidr...@nscdg.com>> Sent: Tuesday, July 28, 2020 8:23 PM> To:
dev@nuttx.apache.org> Subject: RE: Can we implement ctype functions through
table?>> Xiang,>> If there is a small usage do you think flash will grow by 256
bytes? I> would be surprised.>> Should you uses a config option?>> David>>>
-----Original Message-----> From: Xiang Xiao
[mailto:xiaoxiang781...@gmail.com]> Sent: Monday, July 27, 2020 10:40 PM> To:
dev@nuttx.apache.org> Subject: RE: Can we implement ctype functions through
table?>> Decorate the table with IPTR and access the element through
up_romgetc,> just like printf series function.>> > -----Original Message----->
> From: Gregory Nutt <spudan...@gmail.com>> > Sent: Tuesday, July 28, 2020
12:44 PM> > To: dev@nuttx.apache.org> > Subject: Re: Can we implement ctype
functions through table?> >> > What about platforms like AVR? That would not
be a good decision for> > AVR since it is a harvard machine and cannot access
data in ROM> > without special operations.> >> >> > On 7/27/2020 9:55 PM, Xiang
Xiao wrote:> > > Hi all,> > > For example, here is isspace implementation:> > >
# define isspace(c) \> > > ((c) == ' ' || (c) == '\t' || (c) == '\n' ||
(c) == '\r' || \> > > (c) == '\f' || (c) == '\v')> > > The argument of c
will evaluate 6 times, which make the following> > > code suddenly fail:> > >
while (end != begin)> > > {> > > If (!isspace(*--end))> > > {> >
> break;> > > }> > > }> > > But it work well with other
libc implementation, because all other> > > libc utilize a table to classify
the char type:> > >
https://github.com/bminor/newlib/blob/master/newlib/libc/include/cty> > > pe> >
> .h#L97> > > https://github.com/bminor/glibc/blob/master/ctype/ctype.h#L197> >
> and the argument only need evaluate once.> > > So my question is: can we
implement ctype functions through table to> > > improve the compatibility?> > >
Yes, the table need take more 256 bytes ROM space, but the complex> > >
expression used in NuttX also bloat the code size, especially> > > considering
ctype function is used very frequently.> > >> > > Thanks> > > Xiang> > >
