In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Tom Yu) writes:
>>>>>> "jerry" == Jerry Heyman <[EMAIL PROTECTED]> writes:
>
>jerry> In article <ah74fd$5v4$[EMAIL PROTECTED]>,
>jerry> [EMAIL PROTECTED] (Jerry Heyman) writes:
>>> In article <[EMAIL PROTECTED]>,
>>> [EMAIL PROTECTED] (Sam Hartman) writes:
>>>> I'd step through login in a debugger and see where it hangs. If you
>>>> cannot do that, then start inserting debugging print statements and
>>>> binary search where it hangs.
>>>
>>>
>>> #ifdef __hpux
>>> strcpy(utmp_id, cp);
>>> #else
>>> if (len > 2 && *(cp - 1) != '/')
>>> sprintf(utmp_id, "k%s", cp - 1);
>>> else
>>> sprintf(utmp_id, "k0%s", cp);
>>> #endif
>>> strncpy(utx.ut_id, utmp_id, sizeof(utx.ut_id));
>
>jerry> Hate to follow up my own post, but the above strncpy resolves
>jerry> to
>jerry> strncpy (utx.ut_id, utmp_id, 0)
>
>jerry> And the quite a bit more is being copied than anticipated. The
>jerry> modification I made is:
>
>jerry> strncpy(utx.ut_id, utmp_id, sizeof(utmp_id));
>
>That seems wrong. Why is sizeof(utx.ut_id) zero? It shouldn't be.
I tend to agree. But doing a printf() prior to the strncpy()
showed that utx.ut_id was zero length, and strlen on it returned 0.
This may be an underlying problem with the OS.
>In any case, using sizeof(utmp_id) can result in bad things if
>sizeof(utx.ut_id) is less than sizeof(utmp_id).
Agreed. Unfortunately what I was seeing was that the copy
would copy 14 characters, rather than the four that the field
is supposed to hold. Once that happened, things went real bad
real fast.
>---Tom
>________________________________________________
jerry
--
Jerry Heyman 919.224.1442 | IBM SWG/Tivoli Software|"Software is the
Build Infrastructure Architect| 3901 S Miami Blvd | difference between
[EMAIL PROTECTED] | Durham, NC 27703 | hardware and reality"
http://vcard.acm.org/~heymanj
________________________________________________
Kerberos mailing list [EMAIL PROTECTED]
http://mailman.mit.edu/mailman/listinfo/kerberos
