Change to getlogin

[Bill Capen]

Hi,

My company's aplication was recently impacted by a change to the functionality in the "getlogin" call. This was discovered while re-compiling our application under HPUX 11.0. Is anyone aware if HP will be distributing this same change to getlogin for the 10.x series?

TIA
Bill Capen

[Andreas Voss]

Hi,

On HP-UX 11.00 man getlogin says:
WARNINGS
Users of getlogin_r() should note getlogin_r() now conforms with the
POSIX.1c Threads standard. The old prototype of getlogin_r() is supported for compatibility with existing DCE applications only.

On HP-UX 10.20 man getlogin says:
WARNINGS
Users of getlogin_r() should also note that the prototype of this
function will change in the next release for conformance with the new
POSIX Threads standard.

Regards

[Alex Glennie]

What exactly is the problem ? sounds to me as if your application may have been impacted by changes to libc.1 and/or the way it talks to a 64 bit kernel ?

If this is the case it's not so much the O/S but the revision of the lib and / or 32/64 bit compatibility etc ...

Perhaps you could detail.

It's very unlikely HP would back port functionality to an Old O/S.

[Bill Capen]

Expansion of issue:

We are working with a legacy application, that was using "getlogin" to determine if a user would be allowed to perform certain functionality.

After compiling on hpux 11, 32 bit mode and attempting to execute, getlogin was consistantly returning an error condition. I opened a call with HP, and their response was that "it has been fixed to work exactly like the man page entry", specifically :

At least one of the standard input, standard output, or standard error
must be a terminal. For the first of these found that is a terminal,
a user must have logged in on that terminal, and that terminal must be
the controlling terminal of the session leader process of the calling
process's session.

We have managed to get past this issue for hpux 11, but we currently have many clients operating under hpux 10.2. My concern, is that if this is considered a "fix", that a future patch bundle may have this in it, which would bring our 10.2 clients to a halt.

Bill

[Alan Riggs]

That is always a danger. My only advice would be: you are aware of the problem, you know the cause of teh problem, you know the command involved -- don't apply any patches that update said command.