#1983 closed defect (fixed)

cpukit/libnetworking/libc/gethostbyht.c:226:12: warning: ordered comparison of pointer with integer zero

Reported by: Ralf Corsepius Owned by: Eric Norum
Priority: normal Milestone: 4.11
Component: network/legacy Version: 4.11
Severity: major Keywords:
Cc: joel.sherrill@…, chrisj@… Blocked By:
Blocking:

Description

Building RTEMS raises the warning from the subject.

The part of the code this warning points to is the "if (hostf<0) return 0" line from the fragment below:
...
static FILE *hostf = NULL;
...
struct hostent* gethostent_r(char* buf, int len)
{
...

if (hostf<0) return 0;
fseek(hostf,0,SEEK_END);
curlen=ftell(hostf);
fseek(hostf,0,SEEK_SET);

...

I do not understand how this code is supposed to work and believe it has never worked.

ATM, my best guess is, this "hostf<0" should be "hostf == 0" (Abort if file has not already been opened) - Agreed?

AFAIS, this bug is present in all versions of RTEMS >= 4.7.

Besides this, this code is really ancient/outdated and could use a major upgrade.

Change History (4)

comment:1 Changed on Dec 7, 2011 at 5:05:20 AM by Ralf Corsepius

Cc: chrisj@… joel.sherrill@… added

comment:2 Changed on Dec 8, 2011 at 6:10:27 AM by Ralf Corsepius

Resolution: fixed
Status: newclosed

comment:3 Changed on Dec 8, 2011 at 1:51:50 PM by Joel Sherrill

I have asked everyone who committed to the branches to do this. I just double check it at release time.

Reconstructing what happened and why was a real pain in the %$ as part of the release process. Many hands doing light incremental work saves a lot of work doing forensic analysis to figure out what changed.

No it isn't written down. But there aren't many committers and most bugs fixed on branches have been committed by me. Where should it be written down?

Any developer who views adding one line to a Wiki page to documenting changes along a release branch as an unnecessary burden needs to go work on a project with serious CM. Many of our users have CM processes that require some serious paperwork to make a change after a code freeze. We are a serious project for serious applications. We need to treat release branches in a professional manner and follow best, but light weight, practices.

Replying to comment:5:

Replying to comment:4:

When you apply a patch or any change to a release branch after a .0 release, it
needs to be noted in the release notes for the next release. The "next release
notes" grow and are a factor in deciding when to cut them.

Well, I don't recall such a regulation has ever existed since RTEMS exists nor
do I recall such a proposal having been decided upon by the SC.

... I recall you (the release manager) to have collected them around release
times.

http://www.rtems.org/wiki/index.php/4.9_Release_Notes#Release_4.9.7_Changes
http://www.rtems.org/wiki/index.php/4.10_Release_Notes#Release_4.10.2_Changes

FWIW any new features or compatibility changes should be noted in the "next
major release" page which is
http://www.rtems.org/wiki/index.php/4.11_Release_Notes

By writing these as we go, it really removes what used to be a burden at
release time.

Well, I guess, I don't need to mention that such regulations/bureaucracy
encourages contributors to apply a differnent strategy: Not to fix bugs in
release branches.

comment:4 Changed on Nov 24, 2014 at 6:58:28 PM by Gedare Bloom

Version: HEAD4.11

Replace Version=HEAD with Version=4.11 for the tickets with Milestone >= 4.11

Note: See TracTickets for help on using tickets.