[GRASS-dev] r.colors: rules file list unsorted

[Glynn Clements]

Paul Kelly wrote:

> > However, I'm still unsure whether we might have problems due to
> > requiring some unspecified header in order to get "struct winsize".
> > Bear in mind that this is libgis, and if libgis fails to compile so
> > does everything else. Personally, I'd be inclined to just hard-code a
> > setting of 80 columns.
> 
> Hmmm, everywhere I've seen on the web seems to suggest struct winsize is 
> defined in sys/ioctl.h.

That's the case on Linux, but (AFAICT) none of this is specified by
any of the formal Unix standards. In general, ioctl() commands are
specific to a particular type of device; some platforms have each
device's command macros in a header for that particular device.

On Linux, <sys/ioctl.h> includes <bits/ioctls.h>, which defines the
networking commands (SIOC*) directly, and also includes
<asm/ioctls.h>, which defines the TTY commands (TC* and TIOC*) plus
the generic commands (FIO*). Commands for other devices are defined in
device-specific headers (e.g. <linux/cdrom.h> for commands related to
CD drives). It isn't beyond the bounds of possibility that other
platforms may put the TTY commands in a separate header.

> And the mention of winsize is already conditionalised on TIOCGWINSZ
> being defined;

But do we actually *know* that "struct winsize" will be defined in the
same header as TIOCGWINSZ?

> I should think we're pretty safe, no?

It's safe in the sense that the new code *probably* won't result in
GRASS completely failing to compile. To be truly safe, we need a
configure check, e.g. (untested):

	AC_CHECK_MEMBER([struct winsize.ws_col],
		[AC_DEFINE(HAVE_STRUCT_WINSIZE)],[],
		[#include <sys/ioctl.h>])

-- 
Glynn Clements <glynn at gclements.plus.com>