On Thu, 29 Mar 2001, Tom Leete wrote:
> Ulrich Drepper wrote:
> >
> > [EMAIL PROTECTED] writes:
> >
> > > with the new ansi standard, this use of __inline__ is no longer
> > > necessary,
> >
> > This is not correct. Since the semantics of inline in C99 and gcc
> > differ all code which depends
Ulrich Drepper wrote:
>
> [EMAIL PROTECTED] writes:
>
> > with the new ansi standard, this use of __inline__ is no longer
> > necessary,
>
> This is not correct. Since the semantics of inline in C99 and gcc
> differ all code which depends on the gcc semantics should continue to
> use __inline_
[EMAIL PROTECTED] writes:
> with the new ansi standard, this use of __inline__ is no longer
> necessary,
This is not correct. Since the semantics of inline in C99 and gcc
differ all code which depends on the gcc semantics should continue to
use __inline__ since this keyword will hopefully forev
Ulrich Drepper wrote:
>
> [EMAIL PROTECTED] writes:
>
> > with the new ansi standard, this use of __inline__ is no longer
> > necessary,
>
> This is not correct. Since the semantics of inline in C99 and gcc
> differ all code which depends on the gcc semantics should continue to
> use __inline_
Eli Carter wrote:
> Hmm... I used __inline__ because the other function in the same
> headerfile used it... What is the difference between the two, and is
> one depricated now? (And what about in 2.2.x?)
the inline keyword was not added into the c language until the ansi/iso
c99 revision, echoi
Eli Carter wrote:
> Mmmm documentation. Yummy. ;)
>
> When I submitted the original patch, someone wanted to add the ff's
> check as well... to reduce the number of people who make that
> suggestion, perhaps the comment should read:
>
> + * Check that the Ethernet address (MAC) is not a mu
Jeff Garzik wrote:
>
> Eli Carter wrote:
> > The "!(addr[0]&1)" part of the test already catches the ff's case, so
> > that is redundant.
> > Using 6 bytes instead of 7 is an improvement.
>
> oops. Thanks, updated patch attached. My patch also adds inline source
> docs, and uses 'static inline
> hmm, on second thought, I think I would prefer the attached patch
> (compiled but not tested).
Pointless...
> Hardware usually returns all 1's when it's not present, or not working,
> so think checking for addresses filled with 1's is a good idea too.
If the multicast bit is set then we alrea
Eli Carter wrote:
> The "!(addr[0]&1)" part of the test already catches the ff's case, so
> that is redundant.
> Using 6 bytes instead of 7 is an improvement.
oops. Thanks, updated patch attached. My patch also adds inline source
docs, and uses 'static inline' instead of 'static __inline__', tw
Jeff Garzik wrote:
>
> hmm, on second thought, I think I would prefer the attached patch
> (compiled but not tested).
>
> Hardware usually returns all 1's when it's not present, or not working,
> so think checking for addresses filled with 1's is a good idea too.
>
> I also took the patch from
hmm, on second thought, I think I would prefer the attached patch
(compiled but not tested).
Hardware usually returns all 1's when it's not present, or not working,
so think checking for addresses filled with 1's is a good idea too.
I also took the patch from alan's tree and made the memcmp agai
Andrzej Krzysztofowicz wrote:
>
> Hi,
> It looks like a not fully merged patch from Alan's tree:
>
> drivers/net/net.o: In function `pcnet32_open':
> drivers/net/net.o(.text+0x3bb9): undefined reference to `is_valid_ether_addr'
> drivers/net/net.o: In function `pcnet32_probe1':
> drivers/net/n
Hi,
It looks like a not fully merged patch from Alan's tree:
drivers/net/net.o: In function `pcnet32_open':
drivers/net/net.o(.text+0x3bb9): undefined reference to `is_valid_ether_addr'
drivers/net/net.o: In function `pcnet32_probe1':
drivers/net/net.o(.text.init+0x5fa): undefined reference to
13 matches
Mail list logo
