[Toybox] pathological case in sed s///g

[Rich Felker]

On Mon, May 06, 2019 at 10:57:23PM -0700, enh wrote:
> > I know not everything is a macro that can be tested; both myself and
> > folks from other implementations are interested in developing an
> > agreed-upon way to report availability of other extensions via macros,
> > so that configure-style compile/link tests are not needed. This would
> > also facilitate reporting of some things that can't even properly be
> > tested because they would need runtime tests. Unfortunately efforts in
> > this area are stalled from lack of interest. If you or others would
> > like to raise a fuss about making it happen, I'd welcome it.
> 
> wouldn't it be better to have more stuff along the lines of clang's
> __has_builtin/__has_feature/__has_include? they're already very useful
> for getting rid of this kind of stuff, and a __has_function would
> cover most of what's missing.

It probably doesn't, and it's hard to figure out who would be
responsible for providing them. Are you suggesting the compiler would
do it automatically based on presence of a declaration? There's
already an evil hack to check for presence of a declaration and branch
on the result using _Generic, but of course that's after the
preprocessor level. OTOH the preprocessor doesn't and can't have
access to the presence or absence of declarations since everything is
just tokens at that stage.

I think it would be a lot simpler, more flexible, and compatible with
existing compilers (probably a requirement on our side) to simply have
the library define macros for the individual extensions or extension
groups it provides -- basically the same thing as the existing POSIX
macros in unistd.h, but for extensions outside of POSIX. One major
advantage here is that we can also report extensions that are not in
the form of symbols or flags, but some other type of interface -- for
example, support for %m in the printf family.

As a side benefit, this would probably require us to look at,
enumerate, and better document the extensions we support. :-)

Rich