search for: seccode

...; 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, 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? Jack

...op in my way. Perhaps Duncan will give you a proper keyword to search in GCC/LLVM ML archieve. I found a page [1], and iiuc, the C standard allow the implementation (i.e., the compiler) to remove such empty infinite loop. Regards, chenwj [1] https://www.securecoding.cert.org/confluence/display/seccode/MSC40-C.+Do+not+use+an+empty+infinite+loop -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj

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 it internal linkage. By the way, if it was a...

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

...ive you a proper keyword to search in GCC/LLVM > ML archieve. I found a page [1], and iiuc, the C standard allow the > implementation (i.e., the compiler) to remove such empty infinite loop. > > Regards, > chenwj > > [1] > https://www.securecoding.cert.org/confluence/display/seccode/MSC40-C.+Do+not+use+an+empty+infinite+loop >

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 it locally? > > I don't think so. "Redefines it locally" is not the same as giving it internal > linkage....

...is github thread is annoying to follow. I've switched over to the mailing list] On Thu, Nov 07, 2013 at 02:47:04AM -0800, Markus Elfring wrote: > Would you like to avoid that this software will be built on > [undefined > behaviour](https://www.securecoding.cert.org/confluence/display/seccode/CC.+Undefined+Behavior#CC.UndefinedBehavior-ub_106 > "Changes for source code which might cause undefined behaviour?")? Does it actually cause any problem? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests with...

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.

On Sat, Apr 10, 2010 at 08:29:07PM -0500, Peter O'Gorman wrote: > On 04/10/2010 08:01 PM, Jack Howarth wrote: > > > > > bash-3.2$ GCC=/sw/bin/gcc-4 CC=gcc-4 CXX=g++-4 CFLAGS=-I/sw/include CXXFLAGS=-I/sw/include LLVM_CONFIG=/sw/lib/llvm/bin/llvm-config make > > g++-4 -c -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -MD