[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hydra::axp-developer

Title:Alpha Developer Support
Notice:[email protected], 800-332-4786
Moderator:HYDRA::SYSTEM
Created:Mon Jun 06 1994
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3722
Total number of notes:11359

3296.0. "NeoVista Software, Inc." by AMCUCS::SWIERKOWSKI (Quot homines tot sententiae) Mon Mar 10 1997 19:18

    Company Name :  NeoVista Software, Inc.
    Contact Name :  Larry Prevost
    Phone        :  (408) 343-4263
    Fax          :  
    Email        :  "[email protected]"
    Date/Time in :  10-MAR-1997 15:31 
    Originally entered by :  SWIERKOWSKI
    SPE center   :  PAG

    Category     :  Digital UNIX
    OS Version   :  V4.0([a]?)
    System H/W   :  AlphaStation xxx Model x/xxx


    Brief Description of Problem:
    -----------------------------

  Needs help with the C/C++ compiler (V5.5?) and a "gethostid" definition 
conflict.  I did a little research on this in the DIGITAL_UNIX conference
and note 8189.* looks to have already noted this conflict in netdb.h versus
unistd.h and QAR'ed it (on a V4.0a system).  I called Larry and advised him 
that he might try and upgrade to V4.0b to see if that fixes it.  I'll research
this some more to see if the QAR was ever answered, cheers...



						Tony Swierkowski
						Digital Equipment Corporation
						Software Partner Engineering
						Palo Alto, California
						(415) 617-3601
						"[email protected]"
T.RTitleUserPersonal
Name
DateLines
3296.1Mail sent, awaiting response...AMCUCS::SWIERKOWSKIQuot homines tot sententiaeTue Mar 11 1997 15:01121
Greetings!

  After much research here and there, I've sent the following message to Larry
and await a response.  I'll also post a note in the DIGITAL_UNIX conference and
see if any kind of "work-around" is suggested.  FWIW, I did spot a reference
paragraph for "work-arounds" in COMETS, but the one-liner written in it didn't
make any sense to me.  The QAR database on GORGE only answered with "yeah its 
broke, we'll fix it someday"...



						Tony Swierkowski
						Digital Equipment Corporation
						Software Partner Engineering
						Palo Alto, California
						(415) 617-3601
						"[email protected]"


P.S.	Here's the mail I sent Larry...

From:	AMCUCS::SWIERKOWSKI  "Tony Swierkowski" 11-MAR-1997 11:52:19.33
To:	SMTP%"[email protected]"
CC:	SWIERKOWSKI
Subj:	Follow-up info on ASAP call re: gethostid definition conflict...

Greetings!

  Tony Swierkowski @ Digital here with more information re: the call you logged
yesterday about the two (different) definitions for 'gethostid' in:

	/usr/include/netdb.h:extern int gethostid __((void));

            and

        /usr/include/unistd.h:extern long gethostid __((void));

  Per our conversation, a note in an internal support conference for Digital 
UNIX had already noted this anomoly (under Digital UNIX V4.0a at least).  I 
also spotted similar notes against Digital UNIX V4.0 and V4.0b, so the con-
flicting definitions in those two header files aren't fixed in the current 
release (V4.0b) of Digital UNIX.  The person who described the problem against
V4.0a subsequently opened an internal bug report (i.e. "QAR").  The "QAR" number
number doesn't really do you much good (it's an internal bug report filed by 
employees).

  Having said that, I'd recommend you log a bug report directly with the "CSC",
(i.e. Customer Support Center @ 1-800-354-9000).  Such a customer generated bug 
report is called an "SPR" (i.e. Software Performance Report) and thus gives you
something you can track yourself in the future.  FWIW, as a customer generated 
bug, it may also get escalated quicker than internal bug reports logged by 
employees.  When you talk to the CSC, you should also ask about interrim work-
arounds since I have no idea how to advise you on this.

  A follow-up reply to the first base note I found referencing this problem had
also asked about "work-arounds" (if any?), but there have been no responses to
date.  FWIW, I did some poking around on my own V4.0a system and the man page 
for gethostid indicates that the definition for gethostid as an "int" (as speci-
fied in netdb.h) is correct.  This was also apparently true on V3.2[x] systems 
as well (couldn't prove it to myself - I no longer have any V3.2[x] systems).

  In any event, if the definition for gethostid as an "int" is correct, then the
definition for gethostid as a "long" (as specified in unistd.h) is *wrong*,
however...

  I did some poking around in the "QAR" database to see what response (if any?)
official support channels had made to this bug report and the following caught
my eye:

<--- begin partial quote of bug report response --->

	We are still working the correct definition wrt the UNIX98 brand.
	UNIX95 states "long gethostid(void)" is correct, but it should
	return a 32-bit identifier.  For us, long=64 bits.

<--- end partial quote of bug report response --->

  As you may know Digital UNIX V3.2G is an X/Open UNIX 93 branded product and
Digital UNIX V4.0a is an X/Open UNIX 95 branded product.  Per the remark above,
if the UNIX95 specification says gethostid is a "long", then the reference to 
gethostid as an "int" in both the man pages and netdb.h is wrong.

  I did some research on "The Open Group X/Open OSF" web pages, check out:

	http://www.rdg.opengroup.org/public/tech/unix/sus/apis.html

hoping to find out more about "UNIX98" and sure enough it's the follow-on to
the UNIX95 branding work but is still a "work in progress".  The reference to
"gethostid" shows up as "mandatory" in both the UNIX95 branding information as
well as the proposed UNIX98 branding information, but no details on whether it
should be an "int" or a "long".  Per the piece of the bug report response above,
if the UNIX95 branding information indicates that it should be a "long", I'd 
assume this will not change for the UNIX98 specification - but who knows?

  As for Digital UNIX, I have no idea if this means the definition of gethostid
as an "int" (documented in both the man page and is the definition in specified
in netdb.h) is wrong and needs to be corrected *or* whether the definition of 
gethostid as a "long" as specified in unistd.h is really correct per the UNIX95 
specification.

  As I stated, no "work-around" has been mentioned so I'd recommend two things:

1)	Log this directly with the CSC so you can track this yourself.  They 
	may also be able to suggest a work-around until that mythical "future 
	release" comes out someday that fixes this bug.


2)	I'm going to write this up and post it in an informal support conference
	and see if any of the tech-types will bite.  *IF* I get a response, I'll
	send you what I find out.

  Hope this helps, cheers...


						Tony Swierkowski
						Digital Equipment Corporation
						Software Partner Engineering
						Palo Alto, California
						(415) 617-3601
						"[email protected]"

3296.2Possible work-around passed along...AMCUCS::SWIERKOWSKIQuot homines tot sententiaeWed Mar 12 1997 17:4413
Greetings!

  I did get a response to my note (i.e. #9117) I posted in the DIGITAL_UNIX 
conference asking for a possiible "work-around".  I've passed along the gist 
of it to Larry and await a response...


						Tony Swierkowski
						Digital Equipment Corporation
						Software Partner Engineering
						Palo Alto, California
						(415) 617-3601
						"[email protected]"
3296.3Hack up unistd.h, Call closed...AMCUCS::SWIERKOWSKIQuot homines tot sententiaeMon Mar 17 1997 12:1417
Greetings!

  Larry did get back to me re: the mail I sent him last week.  Per the advice
of the owner of the real QAR filed some time ago ago, Larry decided to hack
up unistd.h (and document it!) on his system (V4.0).   In addition, they have
upgraded a few systems to V4.0b and hacked them up as well.  Per the owner of
the QAR, this probably won't be really "fixed" until "Steel" and no patch kit
is expected for V4.0, V4.0a or V4.0b systems.  Larry seems happy, call closed...


						Tony Swierkowski
						Digital Equipment Corporation
						Software Partner Engineering
						Palo Alto, California
						(415) 617-3601
						"[email protected]"