* type qualifiers on function return types?
@ 2005-12-08 12:32 Robert P. J. Day
2005-12-08 16:58 ` Steve Graegert
0 siblings, 1 reply; 10+ messages in thread
From: Robert P. J. Day @ 2005-12-08 12:32 UTC (permalink / raw)
To: C programming list
i was just handed a pile of source code that, upon first build,
complains thusly:
header.h:20: warning: type qualifiers ignored on function return type
header.h:22: warning: type qualifiers ignored on function return type
at those lines, we read:
typedef struct blah {
volatile void (**start_address)(void); <--
volatile char* stack;
volatile void (**manual_start_address)(void); <--
...
which seems to explain the warnings since i never thought you could
add type qualifiers to function return types. or is there something
incredibly clever happening here that i've never seen before? just
wondering why someone would have coded it that way in the first place.
thanks.
rday
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: type qualifiers on function return types? 2005-12-08 12:32 type qualifiers on function return types? Robert P. J. Day @ 2005-12-08 16:58 ` Steve Graegert 2005-12-08 17:43 ` Nate Jenkins 2005-12-08 17:58 ` Robert P. J. Day 0 siblings, 2 replies; 10+ messages in thread From: Steve Graegert @ 2005-12-08 16:58 UTC (permalink / raw) To: C programming list On 12/8/05, Robert P. J. Day <rpjday@mindspring.com> wrote: > > i was just handed a pile of source code that, upon first build, > complains thusly: > > header.h:20: warning: type qualifiers ignored on function return type > header.h:22: warning: type qualifiers ignored on function return type > > at those lines, we read: > > typedef struct blah { > volatile void (**start_address)(void); <-- > volatile char* stack; > volatile void (**manual_start_address)(void); <-- > ... > > which seems to explain the warnings since i never thought you could > add type qualifiers to function return types. or is there something > incredibly clever happening here that i've never seen before? just > wondering why someone would have coded it that way in the first place. Since functions can only return rvalues and the type qualifiers apply only to lvalues, it is meaningless and therefore ignored. \Steve -- Steve Graegert <graegerts@gmail.com> Software Consultant {C/C++ && Java && .NET} Office: +49 9131 7123988 Mobile: +49 1520 9289212 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: type qualifiers on function return types? 2005-12-08 16:58 ` Steve Graegert @ 2005-12-08 17:43 ` Nate Jenkins 2005-12-08 18:00 ` Robert P. J. Day ` (2 more replies) 2005-12-08 17:58 ` Robert P. J. Day 1 sibling, 3 replies; 10+ messages in thread From: Nate Jenkins @ 2005-12-08 17:43 UTC (permalink / raw) To: C programming list I am sure I am not the only one here wondering what "type qualifiers" are. Could someone expound on what they are and why one would use them? Thanks, Nate ----- Original Message ----- From: "Steve Graegert" <graegerts@gmail.com> To: "C programming list" <linux-c-programming@vger.kernel.org> Sent: Thursday, December 08, 2005 8:58 AM Subject: Re: type qualifiers on function return types? > On 12/8/05, Robert P. J. Day <rpjday@mindspring.com> wrote: >> >> i was just handed a pile of source code that, upon first build, >> complains thusly: >> >> header.h:20: warning: type qualifiers ignored on function return type >> header.h:22: warning: type qualifiers ignored on function return type >> >> at those lines, we read: >> >> typedef struct blah { >> volatile void (**start_address)(void); <-- >> volatile char* stack; >> volatile void (**manual_start_address)(void); <-- >> ... >> >> which seems to explain the warnings since i never thought you could >> add type qualifiers to function return types. or is there something >> incredibly clever happening here that i've never seen before? just >> wondering why someone would have coded it that way in the first place. > > Since functions can only return rvalues and the type qualifiers apply > only to lvalues, it is meaningless and therefore ignored. > > \Steve > > -- > > Steve Graegert <graegerts@gmail.com> > Software Consultant {C/C++ && Java && .NET} > Office: +49 9131 7123988 > Mobile: +49 1520 9289212 > - > To unsubscribe from this list: send the line "unsubscribe > linux-c-programming" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: type qualifiers on function return types? 2005-12-08 17:43 ` Nate Jenkins @ 2005-12-08 18:00 ` Robert P. J. Day 2005-12-08 18:07 ` Steve Graegert 2005-12-09 19:25 ` Glynn Clements 2 siblings, 0 replies; 10+ messages in thread From: Robert P. J. Day @ 2005-12-08 18:00 UTC (permalink / raw) To: Nate Jenkins; +Cc: C programming list On Thu, 8 Dec 2005, Nate Jenkins wrote: > I am sure I am not the only one here wondering what "type > qualifiers" are. Could someone expound on what they are and why one > would use them? one of const, volatile or restrict. chances are, unless you're doing low-level hardware programming, "const" is what you'd use most often. for further explanation, see any good C book. rday ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: type qualifiers on function return types? 2005-12-08 17:43 ` Nate Jenkins 2005-12-08 18:00 ` Robert P. J. Day @ 2005-12-08 18:07 ` Steve Graegert 2005-12-08 18:16 ` Nate Jenkins 2005-12-09 19:25 ` Glynn Clements 2 siblings, 1 reply; 10+ messages in thread From: Steve Graegert @ 2005-12-08 18:07 UTC (permalink / raw) To: C programming list On 12/8/05, Nate Jenkins <nate@uniwest.com> wrote: > I am sure I am not the only one here wondering what "type qualifiers" are. > Could someone expound on what they are and why one would use them? My DEC C Compiler documentation gives a good intro to type qualifiers. Here is what is says: There are four type qualifiers: * const * volatile * __unaligned (axp) * __restrict (pointer type only) [now: restrict] "Type qualifiers were introduced by the ANSI C standard to, in part, give you greater control over the compiler's optimizations. The const and volatile type qualifiers can be applied to any type. The __restrict type qualifier can be applied only to pointer types. Note that because the __restrict type qualifier is not part of the 1989 ANSI C standard, this keyword has double leading underscores. The next version (9X) of the C standard is expected to adopt the keyword restrict with the same semantics described in this section. The use of const gives you a method of controlling write access to an object, and eliminates potential side effects across function calls involving that object. This is because a side effect is an alteration of an object's storage and const prohibits such alteration. Use volatile to qualify an object that can be changed by other processes or hardware. The use of volatile disables optimizations with respect to referencing the object. If an object is volatile qualified, it may be changed between the time it is initialized and any subsequent assignments. Therefore, it cannot be optimized." I hope this info was useful enough. \Steve PS: Please do not top post. Thanks. -- Steve Graegert <graegerts@gmail.com> | Blog <http://tikomi.org> Software Consultant {C/C++ && Java && .NET} Office: +49 9131 7123988 Mobile: +49 1520 9289212 > ----- Original Message ----- > From: "Steve Graegert" <graegerts@gmail.com> > To: "C programming list" <linux-c-programming@vger.kernel.org> > Sent: Thursday, December 08, 2005 8:58 AM > Subject: Re: type qualifiers on function return types? > > > > On 12/8/05, Robert P. J. Day <rpjday@mindspring.com> wrote: > >> > >> i was just handed a pile of source code that, upon first build, > >> complains thusly: > >> > >> header.h:20: warning: type qualifiers ignored on function return type > >> header.h:22: warning: type qualifiers ignored on function return type > >> > >> at those lines, we read: > >> > >> typedef struct blah { > >> volatile void (**start_address)(void); <-- > >> volatile char* stack; > >> volatile void (**manual_start_address)(void); <-- > >> ... > >> > >> which seems to explain the warnings since i never thought you could > >> add type qualifiers to function return types. or is there something > >> incredibly clever happening here that i've never seen before? just > >> wondering why someone would have coded it that way in the first place. > > > > Since functions can only return rvalues and the type qualifiers apply > > only to lvalues, it is meaningless and therefore ignored. > > > > \Steve > > > > -- > > > > Steve Graegert <graegerts@gmail.com> > > Software Consultant {C/C++ && Java && .NET} > > Office: +49 9131 7123988 > > Mobile: +49 1520 9289212 > > - > > To unsubscribe from this list: send the line "unsubscribe > > linux-c-programming" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: type qualifiers on function return types? 2005-12-08 18:07 ` Steve Graegert @ 2005-12-08 18:16 ` Nate Jenkins 0 siblings, 0 replies; 10+ messages in thread From: Nate Jenkins @ 2005-12-08 18:16 UTC (permalink / raw) To: C programming list >> I am sure I am not the only one here wondering what "type qualifiers" >> are. >> Could someone expound on what they are and why one would use them? > > My DEC C Compiler documentation gives a good intro to type qualifiers. > Here is what is says: > > There are four type qualifiers: > > * const > * volatile > * __unaligned (axp) > * __restrict (pointer type only) [now: restrict] > > "Type qualifiers were introduced by the ANSI C standard to, in part, > give you greater control over the compiler's optimizations. The const > and volatile type qualifiers can be applied to any type. The > __restrict type qualifier can be applied only to pointer types. > > Note that because the __restrict type qualifier is not part of the > 1989 ANSI C standard, this keyword has double leading underscores. The > next version (9X) of the C standard is expected to adopt the keyword > restrict with the same semantics described in this section. > > The use of const gives you a method of controlling write access to an > object, and eliminates potential side effects across function calls > involving that object. This is because a side effect is an alteration > of an object's storage and const prohibits such alteration. > > Use volatile to qualify an object that can be changed by other > processes or hardware. The use of volatile disables optimizations with > respect to referencing the object. If an object is volatile qualified, > it may be changed between the time it is initialized and any > subsequent assignments. Therefore, it cannot be optimized." > > I hope this info was useful enough. > > \Steve > > PS: Please do not top post. Thanks. > > -- > > Steve Graegert <graegerts@gmail.com> | Blog <http://tikomi.org> > Software Consultant {C/C++ && Java && .NET} > Office: +49 9131 7123988 > Mobile: +49 1520 9289212 > > Thanks for the info Robert and Steve. Sometimes I forget the fancy names of these things. Yes, "const" is probably the most commonly used one... Nate ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: type qualifiers on function return types? 2005-12-08 17:43 ` Nate Jenkins 2005-12-08 18:00 ` Robert P. J. Day 2005-12-08 18:07 ` Steve Graegert @ 2005-12-09 19:25 ` Glynn Clements 2 siblings, 0 replies; 10+ messages in thread From: Glynn Clements @ 2005-12-09 19:25 UTC (permalink / raw) To: Nate Jenkins; +Cc: C programming list Nate Jenkins wrote: > I am sure I am not the only one here wondering what "type qualifiers" are. > Could someone expound on what they are and why one would use them? For a precise definition, see §6.7.3 of the C99 draft, at: http://www.open-std.org/jtc1/sc22/open/n2794/n2794.txt The most useful is "const", which tells the compiler to generate a warning if anything tries to modify the target. Also, if a function argument is a pointer to a const target, the compiler can assume that the target will not be modified. The "volatile" qualifier indicates that any reads or writes must be performed exactly as indicated by the code, and cannot be optimised away (e.g. caching the value in a register). It is used if the target can be read or written by mechanisms which aren't visible to the compiler (hardware, other threads, signal handlers, etc). The "restrict" qualifier is new in C99 and allows additional optimisations. It only applies to pointers, and asserts that the location to which the pointer points will only be read or written through that pointer. -- Glynn Clements <glynn@gclements.plus.com> - To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: type qualifiers on function return types? 2005-12-08 16:58 ` Steve Graegert 2005-12-08 17:43 ` Nate Jenkins @ 2005-12-08 17:58 ` Robert P. J. Day 2005-12-09 19:03 ` Glynn Clements 1 sibling, 1 reply; 10+ messages in thread From: Robert P. J. Day @ 2005-12-08 17:58 UTC (permalink / raw) To: Steve Graegert; +Cc: C programming list On Thu, 8 Dec 2005, Steve Graegert wrote: > On 12/8/05, Robert P. J. Day <rpjday@mindspring.com> wrote: > > > > i was just handed a pile of source code that, upon first build, > > complains thusly: > > > > header.h:20: warning: type qualifiers ignored on function return type > > header.h:22: warning: type qualifiers ignored on function return type > > > > at those lines, we read: > > > > typedef struct blah { > > volatile void (**start_address)(void); <-- > > volatile char* stack; > > volatile void (**manual_start_address)(void); <-- > > ... > > > > which seems to explain the warnings since i never thought you > > could add type qualifiers to function return types. or is there > > something incredibly clever happening here that i've never seen > > before? just wondering why someone would have coded it that way > > in the first place. > > Since functions can only return rvalues and the type qualifiers > apply only to lvalues, it is meaningless and therefore ignored. that's what i thought but, since i'm still working on the intricacies of the language, whenever i come across something that mysterious, i always assume it's just some idiomatic cleverness i've never seen before. of course, after that, i finally figure out it was just bad programming. :-( rday p.s. i'm not *trying* to ask dumb questions. i am merely succeeding. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: type qualifiers on function return types? 2005-12-08 17:58 ` Robert P. J. Day @ 2005-12-09 19:03 ` Glynn Clements 2005-12-09 19:04 ` Robert P. J. Day 0 siblings, 1 reply; 10+ messages in thread From: Glynn Clements @ 2005-12-09 19:03 UTC (permalink / raw) To: Robert P. J. Day; +Cc: Steve Graegert, C programming list Robert P. J. Day wrote: > > > i was just handed a pile of source code that, upon first build, > > > complains thusly: > > > > > > header.h:20: warning: type qualifiers ignored on function return type > > > header.h:22: warning: type qualifiers ignored on function return type > > > > > > at those lines, we read: > > > > > > typedef struct blah { > > > volatile void (**start_address)(void); <-- > > > volatile char* stack; > > > volatile void (**manual_start_address)(void); <-- > > > ... > > > > > > which seems to explain the warnings since i never thought you > > > could add type qualifiers to function return types. or is there > > > something incredibly clever happening here that i've never seen > > > before? just wondering why someone would have coded it that way > > > in the first place. > > > > Since functions can only return rvalues and the type qualifiers > > apply only to lvalues, it is meaningless and therefore ignored. > > that's what i thought but, since i'm still working on the intricacies > of the language, whenever i come across something that mysterious, i > always assume it's just some idiomatic cleverness i've never seen > before. > > of course, after that, i finally figure out it was just bad > programming. :-( Did you mean to declare the pointers as "volatile", rather than the function's return value? Pointer qualifiers go after the "*", e.g. typedef struct blah { void (**volatile start_address)(void); char* volatile stack; void (**volatile manual_start_address)(void); ... -- Glynn Clements <glynn@gclements.plus.com> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: type qualifiers on function return types? 2005-12-09 19:03 ` Glynn Clements @ 2005-12-09 19:04 ` Robert P. J. Day 0 siblings, 0 replies; 10+ messages in thread From: Robert P. J. Day @ 2005-12-09 19:04 UTC (permalink / raw) To: Glynn Clements; +Cc: Steve Graegert, C programming list On Fri, 9 Dec 2005, Glynn Clements wrote: > Did you mean to declare the pointers as "volatile", rather than the > function's return value? > > Pointer qualifiers go after the "*", e.g. > > typedef struct blah { > void (**volatile start_address)(void); > char* volatile stack; > void (**volatile manual_start_address)(void); > ... it wasn't what *i* was declaring, this was code i inherited from elsewhere and it was exactly as i posted it earlier, so i think we've established that, yes, it was silly code. rday ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2005-12-09 19:25 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-12-08 12:32 type qualifiers on function return types? Robert P. J. Day 2005-12-08 16:58 ` Steve Graegert 2005-12-08 17:43 ` Nate Jenkins 2005-12-08 18:00 ` Robert P. J. Day 2005-12-08 18:07 ` Steve Graegert 2005-12-08 18:16 ` Nate Jenkins 2005-12-09 19:25 ` Glynn Clements 2005-12-08 17:58 ` Robert P. J. Day 2005-12-09 19:03 ` Glynn Clements 2005-12-09 19:04 ` Robert P. J. Day
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).