Move POSIX wrappers to wrapper folder

While reviewing some changes, I stumbled upon octave_strcasecmp and octave_strncasecmp in liboctave/util/lo-cutils.c. They are wrapping the C functions strcasecmp and strncasecmp. Those aren’t part of any C standard but defined by POSIX. On non-POSIX platforms, we are using gnulib replacement functions IIUC.
Should we move these wrappers to the wrapper directory where the other gnulib wrappers are?

2 Likes

It makes sense to me to organize all wrappers in the same folder. +1 vote from me.

Yes, I agree, we should use gnulib where we can and group all the wrapper functions together.

I pushed a change here that adds a dedicated wrapper for those functions:
octave: 5d379d2ad903 (gnu.org)

The only remaining function in the old C wrapper file is qsort. I can’t find it anywhere in our codebase.
Should we deprecate that header (lo-cutils.h) and eventually remove it?

Btw: What’s up with the gnulib repository. The buildbots fail repeatedly checking it out…

Edit: Git on Savannah seems to have migrated to new hardware:

Might be the reason for the recent issues while pulling gnulib…

Do we even need to go through the deprecation process or can we just remove it? Just like you, I can’t find qsort used in the codebase. If I try hg log -k qsort to see if it showed up in log files I find

changeset:   8503:8ba2ee57c594
user:        Jaroslav Hajek <highegg@gmail.com>
date:        Tue Jan 13 12:16:21 2009 +0100
summary:     remove qsort in favor of sort

which implies that qsort hasn’t been around for 12 years. Also, the file lo-cutils.h is not included by itself, but rather through a #include in lo-utils.h where that header file is used in various places. Just to test, I took out #include "lo-cutils.h" and Octave compiles just fine.

We are installing that header currently. So theoretically, user code might be relying on that function.
That in mind, having moved the strcase-functions to the wrappers that we don’t install might also be causing issues for user code.
Moving those functions didn’t cause issues with the subset of packages we are building in MXE Octave. However, that’s just a (non-representative) subset of the user code that might be out there…

Anyway, we could probably just remove that header and wait for bug reports. (I’m not expecting that wrapper to be used…)

I’m happy for Octave’s success as a Free Software project, but I think we often overestimate how much use liboctave sees outside of the Octave interpreter and any packages written specifically for Octave. I just did a quick Google search for dependencies liboctave and I couldn’t find an instance where a program was definitively using liboctave rather than Octave as a whole. In summary, I think Octave packages probably represent greater than 95% of liboctave uses and if MXE Octave is compiling the packages without problem then I don’t think qsort is used anywhere.

1 Like

I agree. Those instances are probably very rare.
But there is probably a lot more .oct file code out there than what we compile in MXE Octave…

I removed those headers locally and tried to recompile all packages that we currently build in MXE Octave. They all succeeded. So I pushed a patch removing that wrapper here:
octave: 00ab5e929111 (gnu.org)

1 Like