Is this 'C'/C++? struct device dev = { .name = "dev0", };

[Tim Clacy]

Is this really C/C++?

struct device
{
char const* name;
};

device dev =
{
.name = "dev",
};

The Linux sources are littered with this kind of structure initialisation;
is it legal C/C++? I've just tried 3 different C/C++ compilers and none of
them accept this kind of member initialisation syntax

.name = "dev"

Is this syntax GNU 'C'-specific?

 

[Matthias Kaeppler]

Is this really C/C++?

struct device
{
char const* name;
};

device dev =
{
.name = "dev",
};

The Linux sources are littered with this kind of structure initialisation;
is it legal C/C++? I've just tried 3 different C/C++ compilers and none of
them accept this kind of member initialisation syntax

.name = "dev"

Is this syntax GNU 'C'-specific?

IIRC, you may use initializers on POD-classes:

struct device
{
char const* name;
};

device dev = { "dev" };

However, the dot-notation and direct member assignment are new to me
(and don't compile with my compiler).

 

[Alf P. Steinbach]

* Tim Clacy:

Is this really C/C++?

struct device
{
char const* name;
};

device dev =
{
.name = "dev",
};

The Linux sources are littered with this kind of structure initialisation;
is it legal C/C++? I've just tried 3 different C/C++ compilers and none of
them accept this kind of member initialisation syntax

.name = "dev"

Is this syntax GNU 'C'-specific?

Probably.

The corresponding standard syntax doesn't allow you to state the member name,

device dev = { "dev" };

It seems to get the Linux source code to compile you'll have to comment out
the member name plus assignment operator; perhaps that can be automated.

 

[Peter MacMillan]

Is this really C/C++?

struct device { char const* name; };
device dev = { .name = "dev" };

The Linux sources are littered with this kind of structure initialisation;
is it legal C/C++? I've just tried 3 different C/C++ compilers and none of
them accept this kind of member initialisation syntax

.name = "dev"

Is this syntax GNU 'C'-specific?

According to:
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Designated-Inits.html

It is part of the C99 standard and is offered as an extension in C89
mode. It mentions also that the extension is not implemented in GNU C++.


--
Peter MacMillan
e-mail/msn: (e-mail address removed)
icq: 1-874-927

GCS/IT/L d-(-)>-pu s()-) a- C+++(++++)>$ UL>$ P++ L+ E-(-) W++(+++)>$
N o w++>$ O !M- V PS PE Y+ t++ 5 X R* tv- b++(+) DI D+(++)>$ G e++ h r--
y(--)

 

[Tim Clacy]

* Tim Clacy:

Probably.

The corresponding standard syntax doesn't allow you to state the
member name,

device dev = { "dev" };

It seems to get the Linux source code to compile you'll have to
comment out the member name plus assignment operator; perhaps that
can be automated.

Hmm, a couple of rhetorical follow-up questions:

1) Why would Linux developers tie themselves to GNU C (or 'C' with freaky
extensions)
Why not use portable 'C' like { /* name = */ "dev" }?

2) Why is GNU C tied to Unix/Linux?
Why would a compiler have dependencies on an OS; it just reads and writes
files? Surely the only OS-dependence is the path name separator; '/' or '\'?

 

[Richard Herring]

2) Why is GNU C tied to Unix/Linux?
Why would a compiler have dependencies on an OS; it just reads and writes
files? Surely the only OS-dependence is the path name separator; '/' or '\'?

Ahem. The whole idea of a "path name" is OS-dependent. \ vs / is the
least of your worries.

 

[Karl Heinz Buchegger]

Hmm, a couple of rhetorical follow-up questions:

1) Why would Linux developers tie themselves to GNU C (or 'C' with freaky
extensions)
Why not use portable 'C' like { /* name = */ "dev" }?

Because writing an operating system is non portable by the very nature
of it. Besides: To which other operating system would you port an
operating system to?

So it makes sense to limit all developers contributing to that operating
system to one and only one compiler.

2) Why is GNU C tied to Unix/Linux?

Who said it is?
GNU C is available for a lot of platforms.

 

[Andrey Tarasevich]

Is this really C/C++?

struct device
{
char const* name;
};

device dev =
{
.name = "dev",
};

The Linux sources are littered with this kind of structure initialisation;
is it legal C/C++?

It is not legal C++. But it is legal C under the new C standard - C99.
It is not legal in the original C (C89/90).

GNU C compiler was offering this syntax as a language extension even
before C99.

It is probably worth noting that meaningful initialization in C only
became possible after C99 allowed middle-of-the-block object
definitions. And it was also offered as an extension in GNU C before C99.

 

[Tim Clacy]

Because writing an operating system is non portable by the very nature
of it. Besides: To which other operating system would you port an
operating system to?

Horse manure; there are hundreds of portable OSs out there. In fact, I can't
think of an embeddable OS that is dependent on a specific compiler (except
Windows CE).

So it makes sense to limit all developers contributing to that
operating system to one and only one compiler.


Who said it is?
GNU C is available for a lot of platforms.

....provided there is a Unix shell emualtor for that platform.

 

[Tim Clacy]

Ahem. The whole idea of a "path name" is OS-dependent. \ vs / is the
least of your worries.

Please list all of the differences between a Unix path-name and a Windows
path-name, besides '/' vs '\'.

 

[Karl Heinz Buchegger]

...provided there is a Unix shell emualtor for that platform.

Not at all.
I don't think that DEC had a Unix shell emulator for their
VAX/VMS (I *know* the had not). Yet there was a GNU C ompiler for it.
Or Cray, or PC running DOS or Windows, or ...

 

[Karl Heinz Buchegger]

Please list all of the differences between a Unix path-name and a Windows
path-name, besides '/' vs '\'.

You know, not all the world is a PC running Windows
On a VAX/VMS a whole path name looks eg. like this
(VMS users may correct me. It has been a long time since
my last visit on a VAX/VMS)

node"username password"::device:[directory]file.file_extension;file_version

So '\' versus '/' is the least of your problems.

 

[msalters]

Richard Herring wrote:

Please list all of the differences between a Unix path-name and a Windows
path-name, besides '/' vs '\'.

All? To name a few:
UNIX is single-root, Windows is multi-root. Windows has an explicit
syntax for UNC paths, \\servername\ . The allowed set of characters
differs. Windows supports multiple streams per file (which to C++
appear as distinct files). The algorithms to determine whether two
files denote the same paths differs. Each root directory on Windows
has a .. entry, the UNIX root doesn't have a ..

Windows filenames are UTF-16, I don't think UNIX pathnames are
standardized to that extent.

Regards,
Michiel Salters

 

[Richard Herring]

Please list all of the differences between a Unix path-name and a Windows
path-name, besides '/' vs '\'.

(a) see the other replies.

(b) since when was "OS" restricted to "Unix or Windows" ?

(c) there was a hint of (b) in my signature.

 

[Karl Heinz Buchegger]

[snip]

(c) there was a hint of (b) in my signature.

I have seen lots of postings from you, but never noticed
that hint. Good to see, that you are on the one and only OS
(God, how I miss VMS)

 

[Tim Clacy]

All? To name a few:
UNIX is single-root, Windows is multi-root. Windows has an explicit
syntax for UNC paths, \\servername\ . The allowed set of characters
differs. Windows supports multiple streams per file (which to C++
appear as distinct files). The algorithms to determine whether two
files denote the same paths differs. Each root directory on Windows
has a .. entry, the UNIX root doesn't have a ..

Windows filenames are UTF-16, I don't think UNIX pathnames are
standardized to that extent.

Regards,
Michiel Salters

Let me re-phrase; which of the following aren't portable:
1) fopen
2) fclose
3) fread
4) fwrite

 

[Richard Herring]

[snip]

(c) there was a hint of (b) in my signature.

I have seen lots of postings from you, but never noticed
that hint. Good to see, that you are on the one and only OS

Not any more, but I have memories :-(

 

[Daniel Cer]

Code like that is really C. To be more specific, it's code that conforms
to the C99 standard.

The code is an example of structure initialization using "designated
initializers". It's something that's not supported by older C standards
like ISO C 89. Further, as far as I know, it's also not supported by the
C++ standard. I think even GNU's C++ compiler will choke on code like that.

As an experiment:

test.c
----------------------------------------------
struct device {
const char *name;
};

struct device dev = { .name ="dev" };
----------------------------------------------

$ gcc test.c -c # works with out a hitch

$ g++ test.c -c # gives the following error message
test.c:7: error: syntax error before `.' token

-Dan