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

Re: ssh success



On Wed, Oct 25, 2000 at 12:31:04PM +0200, Marcus Brinkmann wrote:
> Am Mit, 25 Okt 2000 07:43:37 schrieb Igor Khavkine:
> > On Wed, Oct 25, 2000 at 01:25:55AM +0200, Marcus Brinkmann wrote:
> > > On Tue, Oct 24, 2000 at 07:05:04PM -0500, Neal H Walfield wrote:
> > > > > > openssh itself needed several kludges: I replaced MAXHOSTNAME in a
> > > > > > couple of files with a "enough for everyone" value. Evil, but at the
> > > > > > time I lacked the docs to do it right.
> > > > > 
> > > > > Well, this needs to be fixed with realloc() and a loop.
> > > > 
> > > > How about alloca and asprintf?
> > > 
> > > Well, alloca takes the memory from the stack frame. When this is okay I
> > > don't know. I don't know how huge the stack is on various architectures,
> > > and if this imposes a serious limit.
> > > 
> > > asprintf is not defined by any standard I know of (read: POSIX), so it
> > > imposes compatibility issues across unices. BSD and glibc have it.
> > > 
> > > Thanks,
> > > Marcus
> > 
> > True, but this kind of modification need not work on all platforms. Other
> > platforms are happy with the MAX*LEN macros. But they are needed for the
> > code to work properly on Hurd. And as far as I know the only C library for 
> > Hurd is glibc. All you need is a properly placed #ifdef __GNU__ in the code.
> 
> Using "#ifdef __GNU__" works but is not the Right Thing To Do. There
> might be other systems not imposing such limits, and it's bad style
> to plaster your source with #ifdef this and #ifdef that. It's like
> passing around the "schwarzer peter".
> 
> POSIX clearly defines what you need to do, and following this it will
> work on all POSIX conformant systems without knowing the exact
> architecture. The source can use PATH_MAX if it is defined, and
> otherwise use pathconf, and if this returns 0, adapt. For BSD compatibility,
> you may also check MAXPATHLEN.
> 
> Marcus

Shouldn't concerns about portability be in the minds of upstream maintainers?
What we can do is fix the problem for Hurd first in a manner which is as close 
to The Right Thing as possible and submit the patches to upstream maintainers. 
It should be up to them whether they decide to support other systems other 
then Hurd that do not define MAXPATHLEN et al. The changes that are needed are 
usually intimitely linked with the code and as such should be applied at the 
discretion of the upstream maintainers. There are just too many possible 
systems out there to support by the few people who port packages to Hurd. And 
refusing to use something like asprintf, is just duplicating code which is 
already in the glibc. It should be up to the maintainers if they want to 
eliminate the glibc dependencies.

Igor



Reply to: