Hi...
I am relativ new to the impressive and powerfull C language, but i
thinks it is obsolete...
The idea with header/source files where methods can clash into
eachother i don't like... Look at C# which is much cleaner with
namespaces.
Why has C not namespaces and a "area idea" where some methods and
fields could be hidden from the outside?
Something like:
a_source_file.c:
namespace SomeName(.SomeName)
{
area Stack
{
private int[] myStack;
private void someMethod() {};
public void push(int i) {};
public int pop() {};
}
}
another_source_file.c:
using SomeName(.SomeName);
int main(int argc, char[] *argv)
{
Stack.push(10);
System.printf(Stack.pop());
}
I'm really annoyed ;) Is im the only own with that point of view?
If i was a really good programmer (which i'm not... yet! ;)) i would
developed a compiler and a much more simple (but still impressive and
powerfull) c...
Best and kindest regards
Lasse Espeholt
Jul 12 '06
187  6279 
Flash Gordon <sp**@flash-gordon.me.ukwrites:
jacob navia wrote, On 26/09/07 18:58:
>Richard wrote:
>>Tor Rustad <to********@hotmail.comwrites:
jacob navia wrote:
Charlie Gordon wrote:
[...]
>#ifdef ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
>#define ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
>...
>#endif
>>
>The scheme leaves little room for collisions and can be automated too.
>>
Why not
>
#pragma once
Chapter and verse please.
The book of common sense when using well known compilers, page 1.
It is an answer to problems people might have in C. And good advice
too. If your C *must* be 100% standard compatible amongst ALL compilers
then clearly not. But for a LOT of people using many compilers very
useful to know.
Good advice Jacob.
It is supported by
1) MSVC (windows)
<snip>
>11) The Watcom compiler
Alternatively, you could use the normal method that is supported by,
hold on whilst I count...
Sorry, I lost count whilst counting all of the conforming compilers.
So on the one hand we have a method supported by at least 11 compilers
and used by some people. On the other hand we have the method most
people use that is supported by ALL conforming compilers and probably
most non-conforming compilers as well.
If you can't see how using "#pragma once" is superior in terms of ease
of use and less "intrusion" in "real" code which will never be targeted
at all these platforms that exist in the heavens then god help you.
Charlie Gordon wrote:
>
"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...
pete <pf*****@mindspring.comwrites:
[...]
I like the trailing underscore, because I think that the
header guards should have a unique format that is not
likely to be accidentally written in a non header guard macro.
When I had a file named sort.h, I tried a header guard H_SORT,
but there was a problem because the program also had macros like
B_SORT
I_SORT
S_SORT
Q_SORT
and of course: H_SORT
I kept my H_SORT macro for heapsort,
and changed some other things instead.
At this current time, I'm using H_filename_H.
Presumably the "filename" portion consists only of letters, digits,
and underscores (i.e., you strip the trailing ".h").
I use PROJECTNAME_PATHNAME
with PROJECTNAME is the name of the project in uppercase.
and PATHNAME is the name of the header file including the relative path in
the project hierarchy, uppercased with all non alphanumeric characters
replaced with underscores.
lib/compress/huffman.h in project zipklone would be protected by
#ifdef ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
#define ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
...
#endif
The scheme leaves little room for collisions and can be automated too.
It is not unreasonable.
I will consider it.
Thank you.
--
pete
Richard wrote, On 26/09/07 21:16:
Flash Gordon <sp**@flash-gordon.me.ukwrites:
<snip header guards and suggestion of using #pragma once>
>So on the one hand we have a method supported by at least 11 compilers
and used by some people. On the other hand we have the method most
people use that is supported by ALL conforming compilers and probably
most non-conforming compilers as well.
If you can't see how using "#pragma once" is superior in terms of ease
of use and less "intrusion" in "real" code which will never be targeted
at all these platforms that exist in the heavens then god help you.
If it was standardised then I would use it. However, if you really find
writing three simple lines too hard then God help you.
There are good reasons for writing non-portable code and bad reasons. I
would put replacing three simple lines per header with one simple lines
in the bad camp, especially since you have to understand the method
anyway if you want to be able to read most C code.
--
Flash Gordon
Flash Gordon wrote:
If it was standardised then I would use it. However, if you really find
writing three simple lines too hard then God help you.
There are good reasons for writing non-portable code and bad reasons. I
would put replacing three simple lines per header with one simple lines
in the bad camp, especially since you have to understand the method
anyway if you want to be able to read most C code.
You missed apparently the whole *previous* discussion about the name
conflict potential of the different schemas that the
#ifndef NAME /endif schema needs.
The principal reason for #pragma once is it that it doesn't need
a name.
But now the arguments are known, let's just agree that we disagree.
Richard wrote:
Tor Rustad <to********@hotmail.comwrites:
>jacob navia wrote:
>>Charlie Gordon wrote:
[...]
>>>#ifdef ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
#define ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
...
#endif
The scheme leaves little room for collisions and can be automated too.
Why not
#pragma once
Chapter and verse please.
The book of common sense when using well known compilers, page 1.
Since when did c.l.c degenerate into such lack of common sense? *shocked*
I have never been hit by name collision problems by #ifdef & #define's
in header files, a simple _H suffix after filename works well in practice.
The theoretical issue that implementations has grabbed the whole
E[0-9A-Z]+ name space, is rather a problem when defining your own error
codes.
Good advice Jacob.
Wrong, it was bad advice. It solves no real problem, and breaks
portability. At least 50% of the C compilers I regularly use, was not on
that list.
--
Tor <torust [at] online [dot] no>
jacob navia <ja***@jacob.remcomp.frwrites:
Flash Gordon wrote:
>If it was standardised then I would use it. However, if you really
find writing three simple lines too hard then God help you.
There are good reasons for writing non-portable code and bad
reasons. I would put replacing three simple lines per header with
one simple lines in the bad camp, especially since you have to
understand the method anyway if you want to be able to read most C
code.
You missed apparently the whole *previous* discussion about the name
conflict potential of the different schemas that the
#ifndef NAME /endif schema needs.
The principal reason for #pragma once is it that it doesn't need
a name.
And the principal reason *not* to use it is that it's non-standard and
potentially non-portable.
But now the arguments are known, let's just agree that we disagree.
If you refuse to acknowledge that it's non-standard and potentially
non-portable, this is not just a difference of opinion. There's a
real cost for using it, and you ignore that fact.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Richard wrote:
Keith Thompson <ks***@mib.orgwrites:
>If you want to suggest '#pragma once', that's ok with me, but *please*
don't do so without mentioning that it's non-standard. It's a nice
feature, and I wouldn't mind having it in the standard (though
defining it precisely might be difficult), but there is a cost to
using it.
This is a sensible reply.
There is a chance that the OP was interested in how best to achieve
something. "Best" does not, in his case, necessarily mean using the
standard. Nothing wrong with sharing a little bit of experience with the
usual caveats.
I don't see what benefit #pragma once brings, given its nonstandard cost. Even
if I knew that I'd be using only implementations which supported it, I'd
probably still use the #ifndef trick.
Though you are of course correct that some nonstandard features are both useful
and desirable. This is just not one of them.
--
Philip Potter pgp <atdoc.ic.ac.uk
jacob navia wrote:
>
.... snip ...
>
Why not
#pragma once
Not portable.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
jacob navia wrote:
Richard wrote:
>Tor Rustad <to********@hotmail.comwrites:
>>jacob navia wrote:
.... snip ...
>>>
Why not
#pragma once
Chapter and verse please.
The book of common sense when using well known compilers, page 1.
It is an answer to problems people might have in C. And good
advice too. If your C *must* be 100% standard compatible amongst
ALL compilers then clearly not. But for a LOT of people using
many compilers very useful to know.
It is supported by
.... snip specific list ...
It's terrible advice. Why use something that works on a few
specific systems when you can have a system that works all the time
on all systems?
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
jacob navia <ja***@jacob.remcomp.frwrites:
Richard wrote:
Tor Rustad <to********@hotmail.comwrites:
jacob navia wrote:
Charlie Gordon wrote:
[...]
#ifdef ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
#define ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
...
#endif
The scheme leaves little room for collisions and can be automated too.
Why not
#pragma once
It is supported by
4) gcc (versions later than 3.4) (Unix)
I don't think GCC team would like the feature to be used more than it is
already; they consider it obsolete for at least 5 years: http://gcc.gnu.org/onlinedocs/gcc-3....only%20headers
Yours,
--
Jean-Marc
Richard Harter wrote:
As a matter of curiosity, why can't/don't C implementations use a
#require directive that includes a file if and only if it has not
already been included?
This is *exactly* what
#pragma once
does. It will make that a file
is not included again, what is the same as
#require
Philip Potter <pg*@see.sig.invalidwrites:
Chris Torek writes:
>[argument against #pragma once]
It's interesting that this argument applies not only to #pragma once
but also Objective-C style #import directives.
The manual for GCC's C preprocessor gives a different argument
against #import:
In the Objective-C language, there is a variant of
`#include' called `#import' which includes a file, but does
so at most once. If you use `#import' instead of `#include',
then you don't need the conditionals inside the header file
to prevent multiple inclusion of the contents. GCC permits
the use of `#import' in C and C++ as well as Objective-C.
However, it is not in standard C or C++ and should therefore
not be used by portable programs.
`#import' is not a well designed feature. It requires the
users of a header file to know that it should only be
included once. It is much better for the header file's
implementor to write the file so that users don't need to
know this. Using a wrapper `#ifndef' accomplishes this goal.
--
Ben Pfaff http://benpfaff.org
Philip Potter wrote:
>
.... snip ...
>
It's interesting that this argument applies not only to #pragma
once but also Objective-C style #import directives. However, is
it often the case that when one is compiling a project, one uses
the same file referred to through two different NFS mount points?
Is it so much of a problem that #include guards are definitely
better? After all, they have their own quirks and disadvantages -
not least of which, the possibility for accidental E* namespace
invasion, and the possibility of different headers using the same
#defines.
This cannot occur with #include guards if you use the rule that the
control variable is exactly H_<filenamewith.replacedby_>.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer <cb********@yahoo.comwrites:
Philip Potter wrote:
>>
... snip ...
>>
It's interesting that this argument applies not only to #pragma
once but also Objective-C style #import directives. However, is
it often the case that when one is compiling a project, one uses
the same file referred to through two different NFS mount points?
Is it so much of a problem that #include guards are definitely
better? After all, they have their own quirks and disadvantages -
not least of which, the possibility for accidental E* namespace
invasion, and the possibility of different headers using the same
#defines.
This cannot occur with #include guards if you use the rule that the
control variable is exactly H_<filenamewith.replacedby_>.
I think it can:
#include "driedfruit/date.h"
#include "calendar/date.h"
It is impractical to encode the full path name of a header file since
they often move about or get reused in new projects. Of course, if
you do include some more of the path name in the guard you can hit the
opposite problem: including a file twice when the guard should have
prevented it simply because it happens to be in two places.
Ultimately the only solution is to take care and understand the
mechanism.
--
Ben.
Ben Bacarisse wrote:
CBFalconer <cb********@yahoo.comwrites:
>Philip Potter wrote:
>>>
... snip ...
>>>
It's interesting that this argument applies not only to #pragma
once but also Objective-C style #import directives. However, is
it often the case that when one is compiling a project, one uses
the same file referred to through two different NFS mount points?
Is it so much of a problem that #include guards are definitely
better? After all, they have their own quirks and disadvantages -
not least of which, the possibility for accidental E* namespace
invasion, and the possibility of different headers using the same
#defines.
This cannot occur with #include guards if you use the rule that the
control variable is exactly H_<filenamewith.replacedby_>.
I think it can:
#include "driedfruit/date.h"
#include "calendar/date.h"
In that case the '/' will cause problems. I meant filenames
without paths. Paths are normally controlled through unmentioned
compiler options anyhow. And I have little sympathy for people who
give different files the same name.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
In article <47***************@yahoo.com>
CBFalconer <cb********@maineline.netwrote:
>... I meant filenames without paths. Paths are normally controlled
through unmentioned compiler options anyhow.
Well, some of them, in some cases.
>And I have little sympathy for people who give different files
the same name.
This happens for various reasons. Sometimes a single file gets
two names: "the name we invented" (back in the 1900s perhaps, as
<foo.h>) and "the name in the Standard" (C or POSIX or whatever,
as decided in the 2000s, now <sys/foo.h>). Sometimes two different
modules have files with the same name but a different purpose:
perhaps the Zorg library has "evil.c" and "evil.h" for creating
evil, while the metering library has "evil.c" and "evil.h" for
measuring evil. If you need to meter your evil as well as create
it, you might want to use both.
Of course, name conflicts in general are an issue C pretends it
can ignore -- as we see today with various packages that define
their own BOOL or Bool or Boolean or boolean_t types, for instance.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
CBFalconer <cb********@yahoo.comwrites:
In that case the '/' will cause problems. I meant filenames without
paths. Paths are normally controlled through unmentioned compiler
options anyhow. And I have little sympathy for people who give different
files the same name.
I don't have the luxery of working only with what I've written and I've
spend to much time integrating together things which where not designed to
be integrated (they started in different companies), not to have sympathy
for people struggling with name conflict in general.
Using prefixes help somewhat but the more robust way I'm aware is putting
some generated unique id in the guard (for example combining the time, a
numeric id of the host -- MAC address? -- and a numeric id of the user).
Yours,
--
Jean-Marc
CBFalconer wrote:
Ben Bacarisse wrote:
>CBFalconer <cb********@yahoo.comwrites:
>>Philip Potter wrote:
... snip ...
It's interesting that this argument applies not only to #pragma
once but also Objective-C style #import directives. However, is
it often the case that when one is compiling a project, one uses
the same file referred to through two different NFS mount points?
Is it so much of a problem that #include guards are definitely
better? After all, they have their own quirks and disadvantages -
not least of which, the possibility for accidental E* namespace
invasion, and the possibility of different headers using the same
#defines.
This cannot occur with #include guards if you use the rule that the
control variable is exactly H_<filenamewith.replacedby_>.
I think it can:
#include "driedfruit/date.h"
#include "calendar/date.h"
In that case the '/' will cause problems. I meant filenames
without paths. Paths are normally controlled through unmentioned
compiler options anyhow.
Paths are often partially specified in #include directives. But
regardless of how the path is deduced, headers with the same name will
be a problem.
And I have little sympathy for people who
give different files the same name.
What alternative do you propose to avoid collisions? Should filenames be
allocated like MAC addresses? Chris Torek has already presented some
reasonable situations where it might occur.
--
Philip Potter pgp <atdoc.ic.ac.uk
Philip Potter wrote:
What alternative do you propose to avoid collisions? Should filenames be
allocated like MAC addresses? Chris Torek has already presented some
reasonable situations where it might occur.
Even MAC addresses will not work since a MAC address can have a LOT of
files!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Philip Potter wrote:
CBFalconer wrote:
.... snip ...
>
>And I have little sympathy for people who give different files
the same name.
What alternative do you propose to avoid collisions? Should
filenames be allocated like MAC addresses? Chris Torek has
already presented some reasonable situations where it might occur.
I don't think the problem is all that big. Normally the user has
the choice of filename for at least one of the problem makers.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer wrote:
Philip Potter wrote:
>CBFalconer wrote:
... snip ...
>>And I have little sympathy for people who give different files
the same name.
What alternative do you propose to avoid collisions? Should
filenames be allocated like MAC addresses? Chris Torek has
already presented some reasonable situations where it might occur.
I don't think the problem is all that big. Normally the user has
the choice of filename for at least one of the problem makers.
Only if he wrote them himself.
--
Philip Potter pgp <atdoc.ic.ac.uk
"jacob navia" <ja***@nospam.orgschrieb im Newsbeitrag
news:47**********************@news.orange.fr...
Philip Potter wrote:
>What alternative do you propose to avoid collisions? Should filenames be
allocated like MAC addresses? Chris Torek has already presented some
reasonable situations where it might occur.
Even MAC addresses will not work since a MAC address can have a LOT of
files!
Huh? Allocated _like_ a MAC address, MAC addresses are (supposed to be)
unique, worldwide.
Bye, Jojo
In article <fd**********@online.de"Joachim Schmitz" <jo**@schmitz-digital.dewrites:
....
Huh? Allocated _like_ a MAC address, MAC addresses are (supposed to be)
unique, worldwide.
It is good you wrote "supposed to be", because they are not. Some time
ago we got here a new laptop on the network, but it did not work because
there was already another machine on the network with the same MAC address.
That one was bought in the US and the other in Europe probably had
something to do with it.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
"Dik T. Winter" <Di********@cwi.nla écrit dans le message de news: Jp********@cwi.nl...
In article <fd**********@online.de"Joachim Schmitz"
<jo**@schmitz-digital.dewrites:
...
Huh? Allocated _like_ a MAC address, MAC addresses are (supposed to be)
unique, worldwide.
It is good you wrote "supposed to be", because they are not. Some time
ago we got here a new laptop on the network, but it did not work because
there was already another machine on the network with the same MAC
address.
That one was bought in the US and the other in Europe probably had
something to do with it.
The odds of such a collision be the result of chance are far below those of
winning the Euromillions Grand Prize (130 million EUR and counting)
Did you be any chance install a software on both then reprograms MAC
addresses ?
--
Chqrlie.
"Dik T. Winter" <Di********@cwi.nlschrieb im Newsbeitrag
news:Jp********@cwi.nl...
In article <fd**********@online.de"Joachim Schmitz"
<jo**@schmitz-digital.dewrites:
...
Huh? Allocated _like_ a MAC address, MAC addresses are (supposed to be)
unique, worldwide.
It is good you wrote "supposed to be", because they are not. Some time
ago we got here a new laptop on the network, but it did not work because
there was already another machine on the network with the same MAC
address.
That one was bought in the US and the other in Europe probably had
something to do with it.
That's exactly why said it this way 8-). In my former company there was code
that relied on them to be a) unique and b) unchangable... (using the MAC as
kind of a dongle)
Bye, Jojo
"Joachim Schmitz" <no*********@schmitz-digital.dewrites:
"Dik T. Winter" <Di********@cwi.nlschrieb im Newsbeitrag
news:Jp********@cwi.nl...
>In article <fd**********@online.de"Joachim Schmitz"
<jo**@schmitz-digital.dewrites:
...
Huh? Allocated _like_ a MAC address, MAC addresses are (supposed to be)
unique, worldwide.
It is good you wrote "supposed to be", because they are not. Some time
ago we got here a new laptop on the network, but it did not work because
there was already another machine on the network with the same MAC
address.
That one was bought in the US and the other in Europe probably had
something to do with it.
That's exactly why said it this way 8-). In my former company there was code
that relied on them to be a) unique and b) unchangable... (using the MAC as
kind of a dongle)
Bye, Jojo
Foolish people still use MAC address as the only line of security on
their wireless LANs. More fool them, MAC address imitation is very easy
and very common.
"Richard" <rg****@gmail.comschrieb im Newsbeitrag
news:9l************@news.individual.net...
"Joachim Schmitz" <no*********@schmitz-digital.dewrites:
>"Dik T. Winter" <Di********@cwi.nlschrieb im Newsbeitrag
news:Jp********@cwi.nl...
>>In article <fd**********@online.de"Joachim Schmitz"
<jo**@schmitz-digital.dewrites:
...
Huh? Allocated _like_ a MAC address, MAC addresses are (supposed to
be)
unique, worldwide.
It is good you wrote "supposed to be", because they are not. Some time
ago we got here a new laptop on the network, but it did not work because
there was already another machine on the network with the same MAC
address.
That one was bought in the US and the other in Europe probably had
something to do with it.
That's exactly why said it this way 8-). In my former company there was
code
that relied on them to be a) unique and b) unchangable... (using the MAC
as
kind of a dongle)
Bye, Jojo
Foolish people still use MAC address as the only line of security on
their wireless LANs. More fool them, MAC address imitation is very easy
and very common.
Well, in defense of my old company I must say that this was 14 years ago,
ethernet wasn't that widely available and WLAN not at all...
On Mon, 1 Oct 2007 12:58:58 GMT, "Dik T. Winter" <Di********@cwi.nl>
wrote:
>In article <fd**********@online.de"Joachim Schmitz" <jo**@schmitz-digital.dewrites:
...
Huh? Allocated _like_ a MAC address, MAC addresses are (supposed to be)
unique, worldwide.
It is good you wrote "supposed to be", because they are not. Some time
ago we got here a new laptop on the network, but it did not work because
there was already another machine on the network with the same MAC address.
That one was bought in the US and the other in Europe probably had
something to do with it.
It sounds like either someone is cheating, or the MAC address of one
machine was altered. I've never heard of a case where two vendors were
assigned conflicting address blocks.
OTOH, if the programming software doesn't properly check the limits,
it would be quite easy for a vendor to overrun his allotment without
realizing it.
--
Al Balmer
Sun City, AZ
In article <9l************@news.individual.net>,
Richard <rg****@gmail.comwrote:
>Foolish people still use MAC address as the only line of security on
their wireless LANs. More fool them, MAC address imitation is very easy
and very common.
Some people don't lock their doors. Whether this is a really bad idea
depends where you live, and how valuable your possessions are.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963. ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <9l************@news.individual.net>,
Richard <rg****@gmail.comwrote:
>>Foolish people still use MAC address as the only line of security on
their wireless LANs. More fool them, MAC address imitation is very easy
and very common.
Some people don't lock their doors. Whether this is a really bad idea
depends where you live, and how valuable your possessions are.
-- Richard
Big difference though. People using your Wireless could land you in all
sorts of hot water.
In article <nu************@news.individual.net>, Richard
<rg****@gmail.comwrites
>ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
>In article <9l************@news.individual.net>,
Richard <rg****@gmail.comwrote:
>>>Foolish people still use MAC address as the only line of security on
their wireless LANs. More fool them, MAC address imitation is very easy
and very common.
Some people don't lock their doors. Whether this is a really bad idea
depends where you live, and how valuable your possessions are.
-- Richard
Big difference though. People using your Wireless could land you in all
sorts of hot water.
I turn off the DHCP, use MAC and TCP/IP address, and the router only
accepts those pairings. The wireless is only on when it is needed.
Most routers let you turn it the wireless off. There is no point having
the office wireless on 18:00-08:00 and the home one on 08:00 -18:00 or
thereabouts.
Naturally we use WPA encryption. Not sure what else I can do. However
your security only has to be stronger than the value of the thing it is
protecting. If ti is random snoopers there are other easier targets and
I don't think were are likely to be the target of industrial espionage.
..
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <47***********************@news.free.fr"Charlie Gordon" <ne**@chqrlie.orgwrites:
"Dik T. Winter" <Di********@cwi.nla écrit dans le message de news:
Jp********@cwi.nl...
....
It is good you wrote "supposed to be", because they are not. Some time
ago we got here a new laptop on the network, but it did not work because
there was already another machine on the network with the same MAC
address.
That one was bought in the US and the other in Europe probably had
something to do with it.
The odds of such a collision be the result of chance are far below those of
winning the Euromillions Grand Prize (130 million EUR and counting)
Perhaps.
Did you be any chance install a software on both then reprograms MAC
addresses ?
Yes, after we found the collission. Both machines were installed as out
of the box.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
In article <98********************************@4ax.comAl Balmer <al******@att.netwrites:
On Mon, 1 Oct 2007 12:58:58 GMT, "Dik T. Winter" <Di********@cwi.nl>
wrote:
....
It is good you wrote "supposed to be", because they are not. Some time
ago we got here a new laptop on the network, but it did not work because
there was already another machine on the network with the same MAC address.
That one was bought in the US and the other in Europe probably had
something to do with it.
It sounds like either someone is cheating, or the MAC address of one
machine was altered. I've never heard of a case where two vendors were
assigned conflicting address blocks.
I think some of the vendors are cheating. They were cards from the same
vendor. Apparently the vendor thought that a card bought in Europe would
not enter a network in the US where the MAC address was crucial, and the
other way around.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
"Dik T. Winter" <Di********@cwi.nla écrit dans le message de news: Jp********@cwi.nl...
In article <47***********************@news.free.fr"Charlie Gordon"
<ne**@chqrlie.orgwrites:
"Dik T. Winter" <Di********@cwi.nla écrit dans le message de news:
Jp********@cwi.nl...
...
It is good you wrote "supposed to be", because they are not. Some
time
ago we got here a new laptop on the network, but it did not work
because
there was already another machine on the network with the same MAC
address.
That one was bought in the US and the other in Europe probably had
something to do with it.
The odds of such a collision be the result of chance are far below those
of
winning the Euromillions Grand Prize (130 million EUR and counting)
Perhaps.
Did you be any chance install a software on both then reprograms MAC
addresses ?
Yes, after we found the collission. Both machines were installed as out
of the box.
Do you remeber the makes by any chance ?
--
Chqrlie.
On Oct 1, 8:19 am, "Charlie Gordon" <n...@chqrlie.orgwrote:
"Dik T. Winter" <Dik.Win...@cwi.nla écrit dans le message de news:
Jp8HEA....@cwi.nl...
In article <fdqnug$81...@online.de"Joachim Schmitz"
<j...@schmitz-digital.dewrites:
...
Huh? Allocated _like_ a MAC address, MAC addresses are (supposed to be)
unique, worldwide.
It is good you wrote "supposed to be", because they are not. Some time
ago we got here a new laptop on the network, but it did not work because
there was already another machine on the network with the same MAC
address.
That one was bought in the US and the other in Europe probably had
something to do with it.
The odds of such a collision be the result of chance are far below those of
winning the Euromillions Grand Prize (130 million EUR and counting)
Did you be any chance install a software on both then reprograms MAC
addresses ?
Actually if the vendors are doing their jobs, the odds of a collision
should be zero with UAAs (universally administered addresses). That
being said, more than a few (low-end) vendors have just picked a range
(not infrequently an old ID assigned to a now defunct vendor) and used
it (saves them the $4K to actually get a properly allocated block), or
have just messed up (I know of one vendor who managed an entire
production run of ~20K Ethernet cards programmed with the *same* MAC
address).
Obviously that doesn't apply to LAAs
There was originally consideration given to the idea of just having
each card pick a random 48-bit MAC, and relying on the low odds of two
NICs on a single LAN picking the same address, but that basically
didn't happen, and the managed approach we have now was selected.
In article <47**********************@news.free.fr"Charlie Gordon" <ne**@chqrlie.orgwrites:
"Dik T. Winter" <Di********@cwi.nla écrit dans le message de news:
Jp********@cwi.nl...
In article <47***********************@news.free.fr"Charlie Gordon"
<ne**@chqrlie.orgwrites:
....
Did you be any chance install a software on both then reprograms MAC
addresses ?
Yes, after we found the collission. Both machines were installed as out
of the box.
Do you remeber the makes by any chance ?
No, it is already quite a long time ago.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
"Dik T. Winter" <Di********@cwi.nlwrote:
In article <98********************************@4ax.comAl Balmer <al******@att.netwrites:
On Mon, 1 Oct 2007 12:58:58 GMT, "Dik T. Winter" <Di********@cwi.nl>
wrote:
...
It is good you wrote "supposed to be", because they are not. Some time
ago we got here a new laptop on the network, but it did not work because
there was already another machine on the network with the same MAC address.
That one was bought in the US and the other in Europe probably had
something to do with it.
>
It sounds like either someone is cheating, or the MAC address of one
machine was altered. I've never heard of a case where two vendors were
assigned conflicting address blocks.
I think some of the vendors are cheating. They were cards from the same
vendor.
This came up in the Monastery recently. Apparently, some vendors are not
so much cheating as incompetent.
Richard This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: jerrygarciuh |
last post by:
Hi all,
I was just wondering what popular opinion is on PHP giving this warning:
Warning: Invalid argument supplied for foreach() in
/home/boogerpic/public_html/my.php on line 6
when...
|
by: Kari Laitinen |
last post by:
During the past 15 years I have been writing computer
programs with so-called natural names, which means
that the names (identifiers, symbols) in progarms
are constructed of several natural words....
|
by: David Eng |
last post by:
In replying to P.J. Plauger (...
|
by: Jack Klein |
last post by:
I'm looking for opinions on a C technique I, and others, have used
successfully in the past. While some people swear by, apparently
others swear at it.
Assume a part of a program too large to...
|
by: John Doe |
last post by:
I've been doing some reading/research on parsing simple configuration
files through C, and have heard various opinions on the matter. I'd like
to solicit some opinions and design criteria (as well...
| | |
by: John Swan |
last post by:
Please, I have just created this site and am wondering what your opinion is
from both professionals and amatures or the curious alike.
Any opinions?
www.integrated-dev-sol.co.uk
Remove 123...
|
by: Florian Thiel |
last post by:
Dear PHP web developers,
We are currently researching the ways in which the major web
development platforms differ and in addition to our work with the
Plat_Forms contest, we're now looking for...
|
by: JT |
last post by:
Hi,
I would like opinions on a shareware issue. If shareware uses an
online database to hold registration codes, which get copied locally
and therefore only needs to check online if the...
|
by: happyperson |
last post by:
Hi All,
I want to have a news and product review website. I want an RSS feed, online forum, article submission section, and possibly down the road the ability to upload/download music to this...
|
by: Steve Swift |
last post by:
On page 90 of my O'Reilly "Javascript The definitive guide" 3rd edition
there is an example of an If/Else construct: (some text removed)
If (username != null)
alert("Hello " + username);
else {...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
