RE: Fwd: sed porting trouble

[Schmitz, Joachim]

OK, point taken, leave the patch as it is.
Except for the 32767. This is documented to be the max and more importantly 
used in some header files already, therefore safe enough IMHO.

The -lfloss is being taken care of by the cc wrapper script, so nothing you 
need to be worried about.

The system aims at 100% POSIX compliance, but in some places missed it. In 
other places, where the standard allows some slack, it behaves different than 
most, if not all other kids on the block...

That document you found is a bit outdated, there are more of these 
workaround/additions now. They either provide feature NonStop doesn't have 
otherwise (e.g. adjtime, fsync, the pty family or alloca) or workaround 
implementation specifics that are just unusual on other platforms (e.g. Block 
sizes for read, write) or provide some extra features (e.g. the exec family, 
here we spread the load across CPUs) and also covers the slight differences 
across the different OS releases.

Bye, Jojo
-----Original Message-----
From: Bruno Haible [mailto:address@hidden 
Sent: Saturday, October 02, 2010 3:24 PM
To: Schmitz, Joachim
Cc: Paul Eggert; Paolo Bonzini; 'bug-gnulib'
Subject: Re: Fwd: sed porting trouble

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
preferences.

> 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
documentation).

> 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
gnulib.

I see in HP's documentation
<http://h20338.www2.hp.com/NonStopComputing/downloads/Open_source_WP.pdf>
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').

Bruno