Re: mac.c - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: mac.c
Date
Msg-id 200008021314.JAA01479@candle.pha.pa.us
Whole thread Raw
In response to Re: mac.c  (Larry Rosenman <ler@lerctr.org>)
Responses RE: mac.c
List pgsql-hackers
> > > Any comments at all from anyone on my mail from Sunday Nite on
> > > making the macaddr_manuf function just return a
> > > masked MACADDR (I.E. set the low 3 bytes to 0x00) and how we
> > > do this in the code?
> > 
> > So macaddr_manuf() will be changed to return a mac address with the low
> > bytes set to zero? There is certainly a use for a function like this,
> > along with another function, say ismanuf() or same() or similar() or ??,
> > which takes two mac addresses and compares just the manufacturer's
> > fields. Why not call the "manufacturer's mask" function something like
> > manuf() or brand() or ?? rather than reusing macaddr_manuf() which would
> > become obsolete?
> Sure, I just don't want to make a mistake on coding it. I'm open.
> 
> Since macaddr_manuf() will not be up to date, I'd say lets make
> the new function macaddr_brand, and if someone wants to do the other
> two, fine.  I'd also doc the fact that macaddr_manuf() is deprecated, marked
> for deletion one or two releases down the line (since the table will
> no longer be updated, and is very much outdated). 

We can delete it in 7.1.  No reason to keep it around if the output is
invalid.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Larry Rosenman
Date:
Subject: Re: mac.c
Next
From: "Larry Rosenman"
Date:
Subject: RE: mac.c