468,490 Members | 2,644 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,490 developers. It's quick & easy.

C is too old? opinions?

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 5255
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.
Sep 26 '07 #151
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
Sep 26 '07 #152
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
Sep 26 '07 #153
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.
Sep 26 '07 #154
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>
Sep 26 '07 #155
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"
Sep 26 '07 #156
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
Sep 26 '07 #157
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

Sep 27 '07 #158
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

Sep 27 '07 #159
In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>jacob navia wrote:
>>
... snip ...
>>
Why not

#pragma once

Not portable.
ITYM:

Off topic. Not portable. Cant discuss it here. Blah, blah, blah.

--
Useful clc-related links:

http://en.wikipedia.org/wiki/Aspergers
http://en.wikipedia.org/wiki/Clique
http://en.wikipedia.org/wiki/C_programming_language

Sep 27 '07 #160
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
Sep 27 '07 #161
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
Sep 28 '07 #162
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
Sep 30 '07 #163
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

Oct 1 '07 #164
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.
Oct 1 '07 #165
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

Oct 1 '07 #166
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.
Oct 1 '07 #167
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
Oct 1 '07 #168
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
Oct 1 '07 #169
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
Oct 1 '07 #170
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

Oct 1 '07 #171
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
Oct 1 '07 #172

"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
Oct 1 '07 #173
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/
Oct 1 '07 #174
"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.
Oct 1 '07 #175
"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
Oct 1 '07 #176
"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.
Oct 1 '07 #177
"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...
Oct 1 '07 #178
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
Oct 1 '07 #179
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.
Oct 1 '07 #180
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.
Oct 1 '07 #181
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 \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Oct 1 '07 #182
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/
Oct 3 '07 #183
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/
Oct 3 '07 #184
"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.
Oct 3 '07 #185
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.

Oct 3 '07 #186
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/
Oct 6 '07 #187
"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
Oct 10 '07 #188

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Kari Laitinen | last post: by
29 posts views Thread by David Eng | last post: by
3 posts views Thread by Jack Klein | last post: by
10 posts views Thread by John Swan | last post: by
reply views Thread by Florian Thiel | last post: by
21 posts views Thread by Steve Swift | last post: by
reply views Thread by NPC403 | last post: by
3 posts views Thread by gieforce | last post: by
reply views Thread by theflame83 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.