[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: sed porting trouble

From: Bruno Haible
Subject: Re: Fwd: sed porting trouble
Date: Sat, 2 Oct 2010 15:24:02 +0200
User-agent: KMail/1.9.9

Joachim Schmitz wrote:
> Hmm, if you'd remove the remark about misfeature, esp. in connection with the
> 'reported by' and my name attached to it, I think I could live with this.

I can remove the 'reported by' line. But the misfeature is one. "misfeature" is
a negative but polite term.

The misfeature is not so much the #pragma itself, but the fact that is it
inherited through #include. If in file a.c you write
  #pragma COLUMNS 80
  #include "b.h"
then the max column width applies also to the file b.h. It is obvious that
a.c and b.h may have been created by different people or teams, with different

> And to be really on the safe side, use 32767, the maximum value.

This wouldn't be safe. It is frequent that implementations have off-by-one
errors that cause the maximum documented value to actually not work. For
example, I remember some C compiler had problems when you used the largest
possible 'double' value as a literal, because when converting it to binary,
it produced an overflow internally and wrote an Infinity to the .s file.

> At least 2 of our headers do already, and setting it to 10000 may affect 
> them. 

No. It has no effect on a system header that uses #pragma columns if a gnulib
header uses #pragma columns with a different value (according to the

> But I'm not sure why testing it and only put in the pragma when __TANDEM
> is defined, but almost always (on every other platform) having an empty 
> #ifdef __TANDEM
> #endif
> Simpler would be to have nn all ...in.h files:
> #ifdef __TANDEM
> #pragma columns 32767
> #endif

This would be simpler, but it would cause problems with other compilers.
That's why we use #pragma GCC system_header only when needed. That's also
why Paul said "it's better ... than to play with unportable #pragmas".

> And while at it, it'd help my porting effort it it'd be
> #ifdef __TANDEM
> #pragma columns 32767
> #include <floss.h> /* Freeware Look for OSS */
> #endif
> floss.h (and libfloss.a) contains a lot of the portability stuff we need.

So, this system has some POSIX like APIs, but then it has another layer of
POSIX like APIs on top of it? Argh.

Adding <floss.h> can introduce link failures that can only be fixed by
adding -lfloss on the link command line. Therefore I think this stuff
belongs in the config.in.h and Makefile.am of many packages. Putting it
into gnulib would be wrong, because gnulib controls only parts of
config.in.h but not Makefile.am. And we don't want to augment LIBS in

I see in HP's documentation
that it has workarounds for adjtime, alloca, execv, execve, execvp, fork,
read, readv, select, truncate, write, writev. IMO these workarounds should
be migrated to the NonStop kernel, or to gnulib. The workarounds for read
and write are already in gnulib (modules 'safe-read', 'safe-write').


reply via email to

[Prev in Thread] Current Thread [Next in Thread]