Yes, you are right: function version is still 20Bytes bigger than macro
version. Do you have a better solution to fix this problem?
Just to remind people that my original size concern was not with the
table approach. I think the size if about a wash. Applications that do
a lot of string manipulations will benefit from the change more than
applications that do only a little -- which could even be penalized.
I personally would accept a single a single lookup table in user space.
My size concern is only in the PROTECTED build mode. In that case, the
ROM table would be duplicated: Once in user-space and once in kernel
space. That is the wasteful part because the OS does NOT do any
significant string processing and is a case where there would be an
unnecessary size penalty.
If we ignore libs/ and tools/, there is almost no use of ctype.h in the OS:
./boards/mips/pic32mx/sure-pic32mx/src/pic32mx_lcd1602.c:#include
<ctype.h>
./boards/renesas/m16c/skp16c26/src/m16c_lcd.c:#include <ctype.h>
./drivers/audio/tone.c:#include <ctype.h>
./drivers/syslog/syslog_rpmsg.c:#include <ctype.h>
./fs/dirent/fs_opendir.c:#include <ctype.h>
./fs/fat/fs_fat32dirent.c:#include <ctype.h>
There might be other sneak paths through libc that include ctype.h, but
generally I would say that is a pretty high price to pay to such little
value to the OS. The libc usage of ctype is not in functions normally
used by the OS.
So my proposal was you create some include/nuttx/kctype.h that has
definitions of similarly named functions implemented as simple macros
(like kisdigit() vs. isdigit()) or perhaps even global functions. The
internal OS programming environment does not need to have the creature
comforts of the user application environment. It is not intended to be
easy for application developments. This is Unix for god's sake!
Since the name spaces are separate in the PROTECTED build, we could even
use the standard naming include/nuttx/ctype.h, isdigit(), etc. But we
would need some extra conditioning on !defined (CONFIG_BUILD_FLAT) &&
defined (__KERNEL__).
