are these things labels? 
Author Message
 are these things labels?

I pulled this struct initialization out of the linux 2.4.0-test4 kernel
source for the virtual framebuffer driver ( vfb.c ).
The fb_ops struct definition is mostly a list of function pointers.
The identifiers on the right of the colons are the names of callable
functions.

I wasn't sure what to make of the first element on each line ( i.e. the
identifiers to the left of the colons together with the colons ).

If they are labels, what purpose do they serve? I don't see a switch or
a goto. Are they just eye candy?

static struct fb_ops vfb_ops = {
   owner:      THIS_MODULE,
   fb_get_fix: vfb_get_fix,
   fb_get_var: vfb_get_var,
   fb_set_var: vfb_set_var,
   fb_get_cmap:   vfb_get_cmap,
   fb_set_cmap:   vfb_set_cmap,
   fb_pan_display:   vfb_pan_display,
   fb_ioctl:   vfb_ioctl,

Quote:
};

--



Wed, 15 Jan 2003 03:00:00 GMT  
 are these things labels?

Quote:

> I pulled this struct initialization out of the linux 2.4.0-test4 kernel
> source for the virtual framebuffer driver ( vfb.c ).  The fb_ops struct
> definition is mostly a list of function pointers.  The identifiers on
> the right of the colons are the names of callable functions.

It's important to be aware while reading Linux kernel source code that the
Linux kernel isn't and never has been written in standard C.  From the
very beginning of Linux, it's been written in GNU C and requires gcc to
compile.  It uses all sorts of gcc extensions (not just inline assembly,
although there's certainly plenty of that).

Quote:
> I wasn't sure what to make of the first element on each line ( i.e. the
> identifiers to the left of the colons together with the colons ).
> If they are labels, what purpose do they serve? I don't see a switch or
> a goto. Are they just eye candy?
> static struct fb_ops vfb_ops = {
>    owner:      THIS_MODULE,
>    fb_get_fix: vfb_get_fix,
>    fb_get_var: vfb_get_var,
>    fb_set_var: vfb_set_var,
>    fb_get_cmap:   vfb_get_cmap,
>    fb_set_cmap:   vfb_set_cmap,
>    fb_pan_display:   vfb_pan_display,
>    fb_ioctl:   vfb_ioctl,
> };

This is a gcc extension; see the gcc info pages under "C Extensions",
"Labeled Elements in Initializers".  The owner field of the struct will be
set to THIS_MODULE, the fb_ioctl member will be set to vfb_ioctl, etc.,
and this will work the same regardless of how much the definition of
struct fb_ops is reordered.

--

--



Wed, 15 Jan 2003 03:00:00 GMT  
 are these things labels?

Quote:

> This is a gcc extension; see the gcc info pages under "C Extensions",
> "Labeled Elements in Initializers".  The owner field of the struct
> will be set to THIS_MODULE, ... and this will work the same
> regardless of how much the definition of struct fb_ops is reordered.

Hopefully now that there is a standard syntax for designated
initializers, GCC will support it, and such code can eventually
be converted to Standard C.
--



Wed, 15 Jan 2003 03:00:00 GMT  
 are these things labels?

Quote:

>> This is a gcc extension; see the gcc info pages under "C Extensions",
>> "Labeled Elements in Initializers".  The owner field of the struct will
>> be set to THIS_MODULE, ... and this will work the same regardless of
>> how much the definition of struct fb_ops is reordered.
> Hopefully now that there is a standard syntax for designated
> initializers, GCC will support it,

GCC already does support both the "member:" syntax and the ".member ="
syntax (the latter being the syntax in C99).

Quote:
> and such code can eventually be converted to Standard C.

Some code, perhaps, but the example in question was the Linux kernel,
which I'm quite sure will never be converted to standard C.  (If for no
other reason than writing a kernel without inline assembly would be
impossible, although there are more reasons than just that.)  But yes, the
C99 syntax should be used in preference to the older GCC syntax.

--

--



Thu, 16 Jan 2003 03:00:00 GMT  
 are these things labels?

Quote:

> which I'm quite sure will never be converted to standard C.  (If for no
> other reason than writing a kernel without inline assembly would be
> impossible, although there are more reasons than just that.)

? The PDP-11 UNIX kernel didn't have assembly embedded in the C source,
and I don't think that Plan 9 does either.  Of course, there *was* some
assembly language used, but only in separate modules that were
processed by the assembler *instead of* the C compiler.
--



Fri, 17 Jan 2003 03:00:00 GMT  
 are these things labels?

Quote:



> >> This is a gcc extension; see the gcc info pages under "C Extensions",
> >> "Labeled Elements in Initializers".  The owner field of the struct will
> >> be set to THIS_MODULE, ... and this will work the same regardless of
> >> how much the definition of struct fb_ops is reordered.

> > Hopefully now that there is a standard syntax for designated
> > initializers, GCC will support it,

> GCC already does support both the "member:" syntax and the ".member ="
> syntax (the latter being the syntax in C99).

> > and such code can eventually be converted to Standard C.

> Some code, perhaps, but the example in question was the Linux kernel,
> which I'm quite sure will never be converted to standard C.  (If for no
> other reason than writing a kernel without inline assembly would be
> impossible, although there are more reasons than just that.)  But yes, the
> C99 syntax should be used in preference to the older GCC syntax.

> --

> --


Thanks. That's exactly what I was looking for. I like the '.member =' syntax.

It's clean and immediately obvious what's going on.
--



Fri, 17 Jan 2003 03:00:00 GMT  
 are these things labels?


Quote:


> >> This is a gcc extension; see the gcc info pages under "C
> >> Extensions", "Labeled Elements in Initializers".  The owner
> >> field of the struct will be set to THIS_MODULE, ... and this
> >> will work the same regardless of how much the definition of
> >> struct fb_ops is reordered.

> > Hopefully now that there is a standard syntax for designated
> > initializers, GCC will support it,

> GCC already does support both the "member:" syntax and the
> ".member =" syntax (the latter being the syntax in C99).

> > and such code can eventually be converted to Standard C.

> Some code, perhaps, but the example in question was the Linux
> kernel, which I'm quite sure will never be converted to standard
> C.  (If for no other reason than writing a kernel without inline
> assembly would be impossible, although there are more reasons
> than just that.)  But yes, the C99 syntax should be used in
> preference to the older GCC syntax.

I *suspect* that many of the GCC extensions are there to ease its
use to compile other languages, and they should not be removed.  A
prime example is the ability to nest functions.  This enables use
as a back end for Pascal and Modula, to name only two.

--

 http://www.qwikpages.com/backstreets/cbfalconer/
--



Sat, 25 Jan 2003 03:00:00 GMT  
 are these things labels?

Quote:

> I *suspect* that many of the GCC extensions are there to ease its
> use to compile other languages, and they should not be removed.  A
> prime example is the ability to nest functions.  This enables use
> as a back end for Pascal and Modula, to name only two.

There's no reason nested functions would have to be removed from
the GCC backend (which supports several languages) if it were
removed from the C frontend for GCC (which is C-specific).
--
"doe not call up Any that you can not put downe."
--H. P. Lovecraft
--



Sun, 26 Jan 2003 03:00:00 GMT  
 are these things labels?

Quote:


>> I *suspect* that many of the GCC extensions are there to ease
>> its use to compile other languages, and they should not be
>> removed.  A prime example is the ability to nest functions.
>> This enables use as a back end for Pascal and Modula, to
>> name only two.

>There's no reason nested functions would have to be removed
>from the GCC backend (which supports several languages) if it
>were removed from the C frontend for GCC (which is C-specific).

I disagree.  Once it has been there people may well create a
language translator, at the source level.  The generated C-code
may well be quite opaque, but clean, and specific to supported
extensions.  Doing things this way totally avoids messing with
GCC in any way.

Of course the extension should be controlled by suitable options
at run-time.

I chose nested functions simply as a prime example, because
without them a clean translation from, say Pascal, would involve
creating arbitrary function names and all sorts of nasties and
attendant debugging nuisances.


http://www.qwikpages.com/backstreets/cbfalconer/


 http://www.qwikpages.com/backstreets/cbfalconer/
--



Sun, 26 Jan 2003 03:00:00 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Side Effects: Good Thing or Bad Thing

2. I am new to programming and am lost

3. DLL Hell - I touched the wrong thing, now I am punished.

4. Creating an NT service (am I doing the right thing?)

5. #ifdef THING --> #endif THING, okay?

6. What's the difference between *thing and thing[]???

7. What kind of thing does typeof() take?

8. Pulling things out of a c-string

9. Pointers, Functions and all things fun about C

10. Most pointless thing I have ever seen

11. Difference between two different ways of doing things

12. Nested Scope, good thing ?

 

 
Powered by phpBB® Forum Software