Among other things, Primoz Bratanic has send to me a patch that adds attributes to some of the functions. I think it is a good idea, I can see only avantages to it: - it makes the code more explicit for the reader. - it helps the compiler to produce a more performant binary. - it makes audit easier. I'd like to know whether I can apply this patch. There're two different methods to use the attributes of functions: --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- #ifndef __GNUC__ # define __attribute__(x) /*NOTHING*/ #endif static void __attribute__((noreturn)) usage(void) --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- Or perhaps this one a little friendlier: --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- #ifdef __GNUC__ # define NORETURN __attribute__(noreturn) #else # define NORETURN /*NOTHING*/ #endif static void NORETURN usage(void) --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- -- Nicolas Baradakis
On Sat, Sep 17, 2005 at 05:29:18PM +0200, Nicolas Baradakis wrote:
Among other things, Primoz Bratanic has send to me a patch that adds attributes to some of the functions. I think it is a good idea, I can see only avantages to it: - it makes the code more explicit for the reader. - it helps the compiler to produce a more performant binary. - it makes audit easier.
I'd like to know whether I can apply this patch. There're two different methods to use the attributes of functions:
--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- ##ifndef __GNUC__ ## define __attribute__(x) /*NOTHING*/ ##endif
static void __attribute__((noreturn)) usage(void) --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---
Or perhaps this one a little friendlier:
--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- ##ifdef __GNUC__ ## define NORETURN __attribute__(noreturn) ##else ## define NORETURN /*NOTHING*/ ##endif
static void NORETURN usage(void) --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---
I'm only working with gcc, so I don't mind if we use gcc extensions myself... Are the attributes likely to vary between compilers we care about? (as opposed to simply present or absent) If so, then the latter is neccessary... If not, the former is sufficient, and prolly cleaner. If doing the latter roll out the #defines into a seperate header file, so that porting to other compilers is centralised... (If you weren't going to do that already) Oh wow, I think I just discovered why autoconf was written... ^_^ -- ----------------------------------------------------------- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.Com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ -----------------------------------------------------------
Paul TBBle Hampson wrote:
I'm only working with gcc, so I don't mind if we use gcc extensions myself...
They are indeed gcc extensions, but the #defines make the code compile with other compilers.
Are the attributes likely to vary between compilers we care about? (as opposed to simply present or absent)
If so, then the latter is neccessary... If not, the former is sufficient, and prolly cleaner.
Both versions work with non-gcc compiler. My question is mainly about the preferred coding style. -- Nicolas Baradakis
On Sat, Sep 17, 2005 at 06:24:00PM +0200, Nicolas Baradakis wrote:
Paul TBBle Hampson wrote:
Are the attributes likely to vary between compilers we care about? (as opposed to simply present or absent)
If so, then the latter is neccessary... If not, the former is sufficient, and prolly cleaner.
Both versions work with non-gcc compiler. My question is mainly about the preferred coding style.
Both versions do _nothing_ with non-gcc compilers. I'm talking about the idea that a non-gcc compiler will implement the same thing either with different attribute names, or a different pre-function syntax altogether. If such a compiler exists, and we care about it, we should do the latter as it's easier to extend clearly to cover other compilers. -- ----------------------------------------------------------- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.Com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ -----------------------------------------------------------
Paul TBBle Hampson wrote:
Both versions do _nothing_ with non-gcc compilers. I'm talking about the idea that a non-gcc compiler will implement the same thing either with different attribute names, or a different pre-function syntax altogether.
If such a compiler exists, and we care about it, we should do the latter as it's easier to extend clearly to cover other compilers.
Ah, ok. I completely misunderstood your previous reply. Sorry. -- Nicolas Baradakis
On September 17, 2005 5:29:18 PM +0200 Nicolas Baradakis <nbk@sitadelle.com> wrote:
Among other things, Primoz Bratanic has send to me a patch that adds attributes to some of the functions. I think it is a good idea, I can see only avantages to it: - it makes the code more explicit for the reader. - it helps the compiler to produce a more performant binary. - it makes audit easier.
It's less portable. It adds significant noise. Most attributes do not help the compiler produce a more "performant" binary. Branch prediction is one that helps, but off the top of my head I can't think of any others. Personally, I hate them, but I understand why folks use them. So I'm not objecting to their use, I'm just being argumentative. :-) -frank
Frank Cusack <fcusack@fcusack.com> wrote:
Personally, I hate them, but I understand why folks use them. So I'm not objecting to their use, I'm just being argumentative. :-)
I hate ugly code, too. But if we can add a few things to help catch problems, without significantly damaging the readability of the code, I'm all for it. Alan DeKok.
Nicolas Baradakis <nbk@sitadelle.com> wrote:
Among other things, Primoz Bratanic has send to me a patch that adds attributes to some of the functions. I think it is a good idea, I can see only avantages to it: - it makes the code more explicit for the reader. - it helps the compiler to produce a more performant binary. - it makes audit easier.
Sure.
Or perhaps this one a little friendlier:
--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- #ifdef __GNUC__ # define NORETURN __attribute__(noreturn) #else # define NORETURN /*NOTHING*/ #endif
static void NORETURN usage(void)
Putting #ifdef's in header files is OK. I'm a little more wary about putting them in the source. I'd prefer something like: --- #ifdef __GNUC__ # define VOID void __attribute__(noreturn) #else # define VOID void #endif static VOID usage(void) --- That gets the same effect, and is less awkward to read. Alan DeKok.
Alan DeKok wrote:
Or perhaps this one a little friendlier:
#ifdef __GNUC__ # define NORETURN __attribute__(noreturn) #else # define NORETURN /*NOTHING*/ #endif
static void NORETURN usage(void)
Putting #ifdef's in header files is OK. I'm a little more wary about putting them in the source.
I was planing to add the #defines in a header file of course. These are portability issues, so I think they should go in autoconf.h or in missing.h.
I'd prefer something like:
--- #ifdef __GNUC__ # define VOID void __attribute__(noreturn) #else # define VOID void #endif
static VOID usage(void)
---
That gets the same effect, and is less awkward to read.
I think this syntax is a little confusing. The reader may mistakenly think that the function returns with no value, whereas the attribute of the function means the function never returns. I'd like better "static NORETURN usage(void)" in this case. -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
I think this syntax is a little confusing. The reader may mistakenly think that the function returns with no value, whereas the attribute of the function means the function never returns.
I'd like better "static NORETURN usage(void)" in this case.
Ah, ok. Alan DeKok.
participants (4)
-
Alan DeKok -
Frank Cusack -
Nicolas Baradakis -
Paul TBBle Hampson