Another negative thing about the table driven C type functions is that
in the PROTECTED build, there will need to be two ctyle look-up
tables: One in user space and one in kernel space. So the overhead
will 512, not 256, bytes in that configuration.
Perhaps we would use the macros inside o
Macros that evaluate their parameters more than once are dangerous for a
variety of reasons.
On Wed, Jul 29, 2020 at 11:32 AM David Sidrane wrote:
> K&R warns against using macros in loops. Experienced programmers (especially
> embedded) know not to write code like shown in the "reason" for needi
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 in
some configurations, but breaks in other configurations.
Since the standard confirmation is the most important principle for
NuttX, we have th
Another negative thing about the table driven C type functions is that
in the PROTECTED build, there will need to be two ctyle look-up tables:
One in user space and one in kernel space. So the overhead will 512,
not 256, bytes in that configuration.
Also, a minor correction:
The table look
And if the macro versions are employed a few times then they would quickly
grow larger than the table anyways.
The table access is not free. There is overhead in both cases,
depending primarily on the complexity of the ctype comparison.
For is isdigit() the comparison is currently just:
And if the macro versions are employed a few times then they would quickly
grow larger than the table anyways.
--
Lucas Vinicius Hartmann
Subscription software is ransomware disguised.
Em qua., 29 de jul. de 2020 às 10:41, Gregory Nutt
escreveu:
>
> > What about platforms like AVR? That would
On 7/29/2020 7:41 AM, Gregory Nutt wrote:
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.
This is not a show stopper, at least not for the AVR. While a
table-driven solution i
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.
This is not a show stopper, at least not for the AVR. While a
table-driven solution is not optimal for AVR, it will support acce
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
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
>
>
: 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
> Sent: Tuesday, July 28, 2020 12:44 PM
> To: dev@nuttx.apache.org
> Subj
Decorate the table with IPTR and access the element through up_romgetc, just
like printf series function.
> -Original Message-
> From: Gregory Nutt
> Sent: Tuesday, July 28, 2020 12:44 PM
> To: dev@nuttx.apache.org
> Subject: Re: Can we implement ctype functions through t
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) == '
13 matches
Mail list logo
