similar to: Re: reserved identifier violation (#6)

On Tue, Apr 13, 2010 at 09:01:16AM +0200, Duncan Sands wrote: > Hi Jack, > >> bash-3.2$ gcc-4 hello.c -S -O1 -o - -fplugin=./dragonegg.so >> cc1: error: Cannot load plugin ./dragonegg.so >> dlopen(./dragonegg.so, 10): Symbol not found: _classify_argument > > looks like you forgot to apply the i386_static.diff patch to gcc. > > Ciao, > > Duncan. Duncan,

Hi Jack, > Doesn't i386_static.diff represent a violation of... > > https://www.securecoding.cert.org/confluence/display/seccode/DCL36-C.+Do+not+declare+an+identifier+with+conflicting+linkage+classifications > > since it first declares a function as extern and then > redefines it locally? I don't think so. "Redefines it locally" is not the same as giving

[I'm continuing this on the mailing list only] On Mon, Nov 11, 2013 at 06:14:18AM -0800, Markus Elfring wrote: > How do you think about to replace the prefix "guestfs__" by "guestfs_i"? No, we can't do that because such a symbol could be mistaken for public API (although on platforms which support it, we also use a linker script to avoid exporting symbols which are

On Wed, Nov 14, 2012 at 12:22:33AM -0800, Shuxin Yang wrote: > I do some google, I cannot find the answer... > I check C std, I cannot find answer either. > > Delete infinite empty loop is boring, but if C/C++ lawyers could tell it > is safe to to so, > it would obviate the need to prove a non-countable loop infinite or not > before > DCE can delete it. > > That

On Tue, Apr 13, 2010 at 04:06:45PM +0200, Duncan Sands wrote: > Hi Jack, > >> Doesn't i386_static.diff represent a violation of... >> >> https://www.securecoding.cert.org/confluence/display/seccode/DCL36-C.+Do+not+declare+an+identifier+with+conflicting+linkage+classifications >> >> since it first declares a function as extern and then >> redefines

Hi, dear Wenren: Thank you so much for sharing this info. I really appreciate it. Now I can move on deleting dead non-countable loops. Thank you again! Shuxin On 11/14/12 12:56 AM, 陳韋任 (Wei-Ren Chen) wrote: > On Wed, Nov 14, 2012 at 12:22:33AM -0800, Shuxin Yang wrote: >> I do some google, I cannot find the answer... >> I check C std, I cannot find answer either. >>

Hi all, I am working on a bug, which running PLR on HAWQ. The process hung and can't be terminated. >From my investigation, it seems signal handler 'Rf_onsigusr1' trigger a malloc/free deadlock. The calling stack is below. Thread 1 (Thread 0x7f4c93af48e0 (LWP 431263)): #0 0x00007f4c9015805e in __lll_lock_wait_private () from /lib64/libc.so.6 #1 0x00007f4c900dd16b in

I do some google, I cannot find the answer... I check C std, I cannot find answer either. Delete infinite empty loop is boring, but if C/C++ lawyers could tell it is safe to to so, it would obviate the need to prove a non-countable loop infinite or not before DCE can delete it. That is the answer I'm waiting for to delete a disgusting dead non-countable loop in my way. On 11/14/2012

Redirecting to R-devel I don't recall how long the SUGUSR handlers have been in R -- you can check in svn if you like -- it's been a long time. The intention is for them to serve as an emergency break -- a chance of possibly saving the workspace when you get stuck in an infinite loop in C/Fortran code that cant be interrupted by a SIGINT. This can't be accomplished without doing

On Tue, Jul 23, 2024 at 12:58?PM Christophe JAILLET <christophe.jaillet at wanadoo.fr> wrote: > > Le 15/07/2024 ? 15:15, Ilia Mirkin a ?crit : > > On Mon, Jul 15, 2024 at 7:49?AM Markus Elfring <Markus.Elfring at web.de> wrote: > >> > >> From: Markus Elfring <elfring at users.sourceforge.net> > >> Date: Mon, 15 Jul 2024 13:36:54 +0200 >

Le 15/07/2024 ? 15:15, Ilia Mirkin a ?crit?: > On Mon, Jul 15, 2024 at 7:49?AM Markus Elfring <Markus.Elfring at web.de> wrote: >> >> From: Markus Elfring <elfring at users.sourceforge.net> >> Date: Mon, 15 Jul 2024 13:36:54 +0200 >> >> Single characters should be put into a sequence. >> Thus use the corresponding function ?seq_putc? for one

On Mon, Jul 15, 2024 at 7:49?AM Markus Elfring <Markus.Elfring at web.de> wrote: > > From: Markus Elfring <elfring at users.sourceforge.net> > Date: Mon, 15 Jul 2024 13:36:54 +0200 > > Single characters should be put into a sequence. > Thus use the corresponding function ?seq_putc? for one selected call. > > This issue was transformed by using the Coccinelle

On Tue, Sep 13, 2016 at 1:15 PM, SF Markus Elfring <elfring at users.sourceforge.net> wrote: > From: Markus Elfring <elfring at users.sourceforge.net> > Date: Tue, 13 Sep 2016 13:50:56 +0200 > > Adjust a jump label according to the current Linux coding style convention. I think you mean "goto label". "Jump label" has a different meaning, see

On Tue, Sep 13, 2016 at 1:14 PM, SF Markus Elfring <elfring at users.sourceforge.net> wrote: > From: Markus Elfring <elfring at users.sourceforge.net> > Date: Tue, 13 Sep 2016 13:43:50 +0200 > > The local variable "err" will be set to an appropriate value > by a following statement. > Thus omit the explicit initialisation at the beginning. > >

On Tue, Sep 13, 2016 at 1:12 PM, SF Markus Elfring <elfring at users.sourceforge.net> wrote: > From: Markus Elfring <elfring at users.sourceforge.net> > Date: Tue, 13 Sep 2016 11:32:22 +0200 > > Multiplications for the size determination of memory allocations > indicated that array data structures should be processed. > Thus use the corresponding function

On Tue, Sep 13, 2016 at 1:15 PM, SF Markus Elfring <elfring at users.sourceforge.net> wrote: > From: Markus Elfring <elfring at users.sourceforge.net> > Date: Tue, 13 Sep 2016 13:50:56 +0200 > > Adjust a jump label according to the current Linux coding style convention. I think you mean "goto label". "Jump label" has a different meaning, see

On Tue, Sep 13, 2016 at 1:14 PM, SF Markus Elfring <elfring at users.sourceforge.net> wrote: > From: Markus Elfring <elfring at users.sourceforge.net> > Date: Tue, 13 Sep 2016 13:43:50 +0200 > > The local variable "err" will be set to an appropriate value > by a following statement. > Thus omit the explicit initialisation at the beginning. > >

On Tue, Sep 13, 2016 at 1:12 PM, SF Markus Elfring <elfring at users.sourceforge.net> wrote: > From: Markus Elfring <elfring at users.sourceforge.net> > Date: Tue, 13 Sep 2016 11:32:22 +0200 > > Multiplications for the size determination of memory allocations > indicated that array data structures should be processed. > Thus use the corresponding function

On Tue, Sep 13, 2016 at 02:15:20PM +0200, SF Markus Elfring wrote: > From: Markus Elfring <elfring at users.sourceforge.net> > Date: Tue, 13 Sep 2016 13:50:56 +0200 > > Adjust a jump label according to the current Linux coding style convention. > > Signed-off-by: Markus Elfring <elfring at users.sourceforge.net> Please don't send me such patches, I'm not

On Thu, Nov 07, 2019 at 06:18:14PM +0100, Markus Elfring wrote: > From: Markus Elfring <elfring at users.sourceforge.net> > Date: Thu, 7 Nov 2019 18:05:08 +0100 > > A coccicheck run provided information like the following. > > drivers/gpu/drm/qxl/qxl_kms.c:295:1-7: ERROR: missing iounmap; > ioremap on line 178 and execution via conditional on line 185 > >