From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,71171f53c22d92b5 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-11-14 07:39:13 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.stueberl.de!teaser.fr!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: Duncan Sands Newsgroups: comp.lang.ada Subject: Re: C's trikery semantic opens up backdoor in new Linux kernel Date: Fri, 14 Nov 2003 16:38:08 +0100 Organization: Cuivre, Argent, Or Message-ID: References: <3FB1A63C.9080200@nowhere.com> NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: melchior.cuivre.fr.eu.org 1068824230 23919 80.67.180.195 (14 Nov 2003 15:37:10 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Fri, 14 Nov 2003 15:37:10 +0000 (UTC) To: Georg Bauhaus , comp.lang.ada@ada-france.org Return-Path: User-Agent: KMail/1.5.1 In-Reply-To: Content-Disposition: inline X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.3 Precedence: list List-Id: Gateway to the comp.lang.ada Usenet newsgroup List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: archiver1.google.com comp.lang.ada:2498 Date: 2003-11-14T16:38:08+01:00 On Friday 14 November 2003 16:08, Georg Bauhaus wrote: > Vinzent 'Gadget' Hoefler wrote: > : Of course. But think about it: Isn't it a funny thing that you can do > : a thing efficient enough in Ada just to prevent a problem in C, which > : OTOH you even wouldn't have at all if you'd use Ada in the first > : place? > : > : What's the definition for this sort of stuff called? > > Windows 3.1? Will they still laugh at me now, Duncan? :-) Hey - I liked windows 3.1! After all, it made my OS/2 system look so spiffy. :) By the way, here is an extract from the linux kernel documentation: ------------------- 2) #ifdefs are ugly Code cluttered with ifdefs is difficult to read and maintain. Don't do it. Instead, put your ifdefs in a header, and conditionally define 'static inline' functions, or macros, which are used in the code. Let the compiler optimize away the "no-op" case. Simple example, of poor code: dev = init_etherdev (NULL, 0); if (!dev) return -ENODEV; #ifdef CONFIG_NET_FUNKINESS init_funky_net(dev); #endif Cleaned-up example: (in header) #ifndef CONFIG_NET_FUNKINESS static inline void init_funky_net (struct net_device *d) {} #endif (in the code itself) dev = init_etherdev (NULL, 0); if (!dev) return -ENODEV; init_funky_net(dev); 3) 'static inline' is better than a macro Static inline functions are greatly preferred over macros. They provide type safety, have no length limitations, no formatting limitations, and under gcc they are as cheap as macros. Macros should only be used for cases where a static inline is clearly suboptimal [there a few, isolated cases of this in fast paths], or where it is impossible to use a static inline function [such as string-izing]. 'static inline' is preferred over 'static __inline__', 'extern inline', and 'extern __inline__'.