Now
MAIN commitmail json YAML
src/usr.bin/xlint/common/externs.h@1.10
/
diff
/
nxr@1.10
src/usr.bin/xlint/common/tyname.c@1.20 / diff / nxr@1.20
src/usr.bin/xlint/lint1/decl.c@1.98 / diff / nxr@1.98
src/usr.bin/xlint/lint1/init.c@1.57 / diff / nxr@1.57
src/usr.bin/xlint/lint1/tree.c@1.115 / diff / nxr@1.115
src/usr.bin/xlint/lint2/chk.c@1.31 / diff / nxr@1.31
src/usr.bin/xlint/common/tyname.c@1.20 / diff / nxr@1.20
src/usr.bin/xlint/lint1/decl.c@1.98 / diff / nxr@1.98
src/usr.bin/xlint/lint1/init.c@1.57 / diff / nxr@1.57
src/usr.bin/xlint/lint1/tree.c@1.115 / diff / nxr@1.115
src/usr.bin/xlint/lint2/chk.c@1.31 / diff / nxr@1.31
lint: fix buffer truncation for type names
Previously, most type names had been cut off after 63 significant
characters. In some cases, 127 characters survived, or 255. And for
the debugging messages, sometimes even 1023. This inconsistency was
useless.
It was wrong in the first place to make the caller of the function
tyname responsible for handling the buffer. That's not something a
caller of such a simple function should do. These callers have better
things to do.
The API of the new function type_name is as simple as possible.
In the implementation, the name of the type is generated anew each time.
I just didn't know whether the type details could change, once the type
is initialized, and I didn't want to find out. To be on the safe side,
the resulting type name is cached, independently of the type it was
generated for. Using a trivial, unbalanced binary tree should be good
enough for now.
All this work is necessary to support adding new debug logging, without
being distracted by irrelevant implementation details such as these
buffer sizes. Adding new debug messages should be fun and easy; up to
now, it was overly bureaucratic.
Previously, most type names had been cut off after 63 significant
characters. In some cases, 127 characters survived, or 255. And for
the debugging messages, sometimes even 1023. This inconsistency was
useless.
It was wrong in the first place to make the caller of the function
tyname responsible for handling the buffer. That's not something a
caller of such a simple function should do. These callers have better
things to do.
The API of the new function type_name is as simple as possible.
In the implementation, the name of the type is generated anew each time.
I just didn't know whether the type details could change, once the type
is initialized, and I didn't want to find out. To be on the safe side,
the resulting type name is cached, independently of the type it was
generated for. Using a trivial, unbalanced binary tree should be good
enough for now.
All this work is necessary to support adding new debug logging, without
being distracted by irrelevant implementation details such as these
buffer sizes. Adding new debug messages should be fun and easy; up to
now, it was overly bureaucratic.