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
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 on the gcc
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
[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
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
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,
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, echoing
[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
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__ since
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__ since
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
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
> 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
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__',
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
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':
>
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':
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
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 alan's
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__', two
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 already
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' instead
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
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
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
26 matches
Mail list logo
