Re: [dev] c++-style comments [was fsbm]
On Fri, 7 Nov 2014 01:23:30 +0100 Hiltjo Posthuma hil...@codemadness.org wrote: You are now added to the kickstarter.com assassination objective [1]. From Russia with love, Putin I'm all busy with Poettering and Stallman at the moment, but I added Sylvain to the list now. Cheers FRIGN -- FRIGN d...@frign.de
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 6, 2014 at 6:09 PM, Dimitris Papastamos s...@2f30.org wrote: On Thu, Nov 06, 2014 at 05:56:55PM +0100, Sylvain BERTRAND wrote: On Thu, Nov 06, 2014 at 03:40:56PM +, Dimitris Papastamos wrote: On Thu, Nov 06, 2014 at 04:38:20PM +0100, Sylvain BERTRAND wrote: On a personnal level, I port some of my C99 projects back to C89, since it seems a C89 compiler is easier to write than a C99 compiler, and some part of my code could go in C89 only project (i.e. the linux kernel). the linux kernel is built with gnu99 iirc. Documentation/HOWTO: The kernel is written using GNU C and the GNU toolchain. While it adheres to the ISO C89 standard, it uses a number of extensions that are not featured in the standard. The kernel is a freestanding C environment, with no reliance on the standard C library, so some portions of the C standard are not supported. Arbitrary long long divisions and floating point are not allowed. It can sometimes be difficult to understand the assumptions the kernel has on the toolchain and the extensions that it uses, and unfortunately there is no definitive reference for them. Please check the gcc info pages (`info gcc`) for some information on them. It uses a *lot* of extensions. If I remember correctly, a significant number of gcc extensions were initially driven by the needs of linux kernel programmers. A C89 only compiler would have no hope to build the kernel in any way so I do not see how C89 is relevant here anymore. There is the http://llvm.linuxfoundation.org/index.php/Main_Page project that works towards getting the Kernel to compile with clang. That effort should hopefully increase the standards conformance of Kernel code at least somewhat. Cheers, Silvan
Re: [dev] c++-style comments [was fsbm]
On Fri, Nov 07, 2014 at 10:30:20AM +0100, Silvan Jegen wrote: There is the http://llvm.linuxfoundation.org/index.php/Main_Page llvm/clang is worse than gcc as it's from the start a massive c++ kludge. At least with gcc until its version 4.7, you can bootstrap its compilation with a C only compiler. They should add http://tinycc.linuxfoundation.org/index.php/Main_Page, since tinycc has the decency to be coded in C. :P -- Sylvain
Re: [dev] c++-style comments [was fsbm]
On Fri, Nov 07, 2014 at 03:35:52PM +0100, Sylvain BERTRAND wrote: On Fri, Nov 07, 2014 at 10:30:20AM +0100, Silvan Jegen wrote: There is the http://llvm.linuxfoundation.org/index.php/Main_Page llvm/clang is worse than gcc as it's from the start a massive c++ kludge. At least with gcc until its version 4.7, you can bootstrap its compilation with a C only compiler. Indeed, that fact isn't nice about clang. But besides that it is _much_ nicer than gcc in many regards. Especially the diagnostics are great. Also the codebase looks much more tiny, sane and not so 'grown'. The resulting assembler is not yet on the same quality level as gcc, but they will get there. Kind regards, -Alex
Re: [dev] c++-style comments [was fsbm]
On November 6, 2014 6:34:17 PM CET, Louis Santillan lpsan...@gmail.com wrote: There is one case where C++ style comment create a useful feature that I don't believe C style comments are able to replicate. Some might disagree. In a color syntax highlighting editor in a C99 codebase, you can prefix C style comments with C++ style comments and get single character feature enable/disabling. //* Remove first / to disable this block doSomething(); //*/ In a color syntax highlighting editor, doSomething(); takes on normal highlighting when enabled, and takes on comment colored highlighting when disabled. Visually, that's slightly improved over something like #ifdef DEBUG doSomething(); #endif where you need to know what defines are created in your codebase, and maybe there is a clash with a header or deep in the header chain, and you need to know what defines are created on the command line. On Thu, Nov 6, 2014 at 8:37 AM, Dimitris Papastamos s...@2f30.org wrote: On Thu, Nov 06, 2014 at 10:28:51AM -0500, Bobby Powers wrote: Can someone explain why they think /* */ sucks less than // ? It doesn't seem like it is for compatibility when st and dwm require C99 anyway. An internet search did not turn up much, apologies if I've missed an obvious link or previous discussion. For consistency with multiline comments and for allowing the code to compile with C89. Also // looks terrible. And no, the fact that /* */ cannot be nested is not an argument in favor of //. You disgust me.
Re: [dev] c++-style comments [was fsbm]
Hey...I try. :D On Fri, Nov 7, 2014 at 9:37 AM, koneu kone...@googlemail.com wrote: You disgust me.
Re: [dev] c++-style comments [was fsbm]
On Fri, 07 Nov 2014 18:37:04 +0100 koneu kone...@googlemail.com wrote: You disgust me. You are an official nominee for the 2014 suckless award. Stay tuned! Cheers FRIGN -- FRIGN d...@frign.de
Re: [dev] c++-style comments [was fsbm]
is that different or the same as the kickstarter assassination award? On 7 November 2014 13:07, FRIGN d...@frign.de wrote: On Fri, 07 Nov 2014 18:37:04 +0100 koneu kone...@googlemail.com wrote: You disgust me. You are an official nominee for the 2014 suckless award. Stay tuned! Cheers FRIGN -- FRIGN d...@frign.de
Re: [dev] c++-style comments [was fsbm]
koneu kone...@googlemail.com wrote: You disgust me. You are an official nominee for the 2014 suckless award. Stay tuned! Cheers FRIGN Shouldn't that be the 2014 suckless-less award? Someone's logic is clearly in question.
Re: [dev] c++-style comments [was fsbm]
On Fri, 7 Nov 2014 13:08:47 -0500 Calvin Morrison mutanttur...@gmail.com wrote: is that different or the same as the kickstarter assassination award? How did you know we have a hitlist? :O -- FRIGN d...@frign.de
Re: [dev] c++-style comments [was fsbm]
On 7 November 2014 13:12, FRIGN d...@frign.de wrote: On Fri, 7 Nov 2014 13:08:47 -0500 Calvin Morrison mutanttur...@gmail.com wrote: is that different or the same as the kickstarter assassination award? How did you know we have a hitlist? :O I am in the inner sanctum
Re: [dev] c++-style comments [was fsbm]
On Fri, Nov 07, 2014 at 04:01:28PM +0100, Alexander Huemer wrote: On Fri, Nov 07, 2014 at 03:35:52PM +0100, Sylvain BERTRAND wrote: On Fri, Nov 07, 2014 at 10:30:20AM +0100, Silvan Jegen wrote: There is the http://llvm.linuxfoundation.org/index.php/Main_Page llvm/clang is worse than gcc as it's from the start a massive c++ kludge. At least with gcc until its version 4.7, you can bootstrap its compilation with a C only compiler. Indeed, that fact isn't nice about clang. That fact is a definitive nono. I would reconsidere if re-written in C. I'm stuck with gcc 4.7.x -- Sylvain
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 10:28:51AM -0500, Bobby Powers wrote: Hello, Hiltjo Posthuma wrote: - Don't use C++ style comments (//). I personally find C++ style comments more pleasant on the eyes for single-line comments, and they are part of the C99 spec. Can someone explain why they think /* */ sucks less than // ? It doesn't seem like it is for compatibility when st and dwm require C99 anyway. An internet search did not turn up much, apologies if I've missed an obvious link or previous discussion. I'm external to the project, but here is my guess: cosmestic part of coding guidelines for that project. On a personnal level, I port some of my C99 projects back to C89, since it seems a C89 compiler is easier to write than a C99 compiler, and some part of my code could go in C89 only project (i.e. the linux kernel). My 2c. -- Sylvain
Re: [dev] c++-style comments [was fsbm]
On Thu, 6 Nov 2014 10:28:51 -0500
Bobby Powers bobbypow...@gmail.com wrote:
I personally find C++ style comments more pleasant on the eyes for
single-line comments, and they are part of the C99 spec.
De gustibus non est disputandum. I personally prefer {/*, */}.
Can someone explain why they think /* */ sucks less than // ? It
doesn't seem like it is for compatibility when st and dwm require C99
anyway. An internet search did not turn up much, apologies if I've
missed an obvious link or previous discussion.
There are many ways to show why {/*, */} sucks less than {//}. Here is
one:
If you take a look at C, everything is block-oriented. The smallest
linguistic entity is ...;, followed by (...) and {...}. The
traditional comments /*...*/ are part of this axiomatic system.
This approach is not line-oriented. Taking preprocessor
directives and includes aside, you can literally strip all newlines
from a given C-source and it would still compile.
It's okay that preprocessor directives and includes are an exception
here, given they are normally used before the first function
definition.
C++-style comments don't follow the block orientation. They break it.
Stripping all newlines from a C-source with {//} as a linguistic
subset will break the program. Given we at suckless work according
to the UNIX-philosophy, and even though UNIX-streams are mostly
line-oriented, a C-source should not depend on non-printable characters
to function properly (except for includes and preprocessor directives).
Moreover, if you write multiline-comments and use {/*, */} while at the
same time using {//} for one-liners can really disrupt code consistency,
and in the end make code harder to maintain and augment.
Because of these reasons, it makes sense to forbid C++-style comments
in a general coding convention.
Cheers
FRIGN
--
FRIGN d...@frign.de
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 10:28:51AM -0500, Bobby Powers wrote: Can someone explain why they think /* */ sucks less than // ? It doesn't seem like it is for compatibility when st and dwm require C99 anyway. An internet search did not turn up much, apologies if I've missed an obvious link or previous discussion. For consistency with multiline comments and for allowing the code to compile with C89. Also // looks terrible. And no, the fact that /* */ cannot be nested is not an argument in favor of //.
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 03:40:56PM +, Dimitris Papastamos wrote: On Thu, Nov 06, 2014 at 04:38:20PM +0100, Sylvain BERTRAND wrote: On a personnal level, I port some of my C99 projects back to C89, since it seems a C89 compiler is easier to write than a C99 compiler, and some part of my code could go in C89 only project (i.e. the linux kernel). the linux kernel is built with gnu99 iirc. Documentation/HOWTO: The kernel is written using GNU C and the GNU toolchain. While it adheres to the ISO C89 standard, it uses a number of extensions that are not featured in the standard. The kernel is a freestanding C environment, with no reliance on the standard C library, so some portions of the C standard are not supported. Arbitrary long long divisions and floating point are not allowed. It can sometimes be difficult to understand the assumptions the kernel has on the toolchain and the extensions that it uses, and unfortunately there is no definitive reference for them. Please check the gcc info pages (`info gcc`) for some information on them. Then I guess, it would help to have a C89/C90 base code to start with instead of C99. I wonder how much of the linux kernel tinycc is able to compile. -- Sylvain
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 05:27:06PM +0100, FRIGN wrote:
If you take a look at C, everything is block-oriented. The smallest
linguistic entity is ...;, followed by (...) and {...}. The
traditional comments /*...*/ are part of this axiomatic system.
This approach is not line-oriented.
I have to agree on that.
--
Sylvain
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 05:56:55PM +0100, Sylvain BERTRAND wrote: On Thu, Nov 06, 2014 at 03:40:56PM +, Dimitris Papastamos wrote: On Thu, Nov 06, 2014 at 04:38:20PM +0100, Sylvain BERTRAND wrote: On a personnal level, I port some of my C99 projects back to C89, since it seems a C89 compiler is easier to write than a C99 compiler, and some part of my code could go in C89 only project (i.e. the linux kernel). the linux kernel is built with gnu99 iirc. Documentation/HOWTO: The kernel is written using GNU C and the GNU toolchain. While it adheres to the ISO C89 standard, it uses a number of extensions that are not featured in the standard. The kernel is a freestanding C environment, with no reliance on the standard C library, so some portions of the C standard are not supported. Arbitrary long long divisions and floating point are not allowed. It can sometimes be difficult to understand the assumptions the kernel has on the toolchain and the extensions that it uses, and unfortunately there is no definitive reference for them. Please check the gcc info pages (`info gcc`) for some information on them. It uses a *lot* of extensions. If I remember correctly, a significant number of gcc extensions were initially driven by the needs of linux kernel programmers. A C89 only compiler would have no hope to build the kernel in any way so I do not see how C89 is relevant here anymore.
Re: [dev] c++-style comments [was fsbm]
There is one case where C++ style comment create a useful feature that I don't believe C style comments are able to replicate. Some might disagree. In a color syntax highlighting editor in a C99 codebase, you can prefix C style comments with C++ style comments and get single character feature enable/disabling. //* Remove first / to disable this block doSomething(); //*/ In a color syntax highlighting editor, doSomething(); takes on normal highlighting when enabled, and takes on comment colored highlighting when disabled. Visually, that's slightly improved over something like #ifdef DEBUG doSomething(); #endif where you need to know what defines are created in your codebase, and maybe there is a clash with a header or deep in the header chain, and you need to know what defines are created on the command line. On Thu, Nov 6, 2014 at 8:37 AM, Dimitris Papastamos s...@2f30.org wrote: On Thu, Nov 06, 2014 at 10:28:51AM -0500, Bobby Powers wrote: Can someone explain why they think /* */ sucks less than // ? It doesn't seem like it is for compatibility when st and dwm require C99 anyway. An internet search did not turn up much, apologies if I've missed an obvious link or previous discussion. For consistency with multiline comments and for allowing the code to compile with C89. Also // looks terrible. And no, the fact that /* */ cannot be nested is not an argument in favor of //.
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 05:09:44PM +, Dimitris Papastamos wrote: On Thu, Nov 06, 2014 at 05:56:55PM +0100, Sylvain BERTRAND wrote: On Thu, Nov 06, 2014 at 03:40:56PM +, Dimitris Papastamos wrote: On Thu, Nov 06, 2014 at 04:38:20PM +0100, Sylvain BERTRAND wrote: On a personnal level, I port some of my C99 projects back to C89, since it seems a C89 compiler is easier to write than a C99 compiler, and some part of my code could go in C89 only project (i.e. the linux kernel). the linux kernel is built with gnu99 iirc. Documentation/HOWTO: The kernel is written using GNU C and the GNU toolchain. While it adheres to the ISO C89 standard, it uses a number of extensions that are not featured in the standard. The kernel is a freestanding C environment, with no reliance on the standard C library, so some portions of the C standard are not supported. Arbitrary long long divisions and floating point are not allowed. It can sometimes be difficult to understand the assumptions the kernel has on the toolchain and the extensions that it uses, and unfortunately there is no definitive reference for them. Please check the gcc info pages (`info gcc`) for some information on them. It uses a *lot* of extensions. If I remember correctly, a significant number of gcc extensions were initially driven by the needs of linux kernel programmers. A C89 only compiler would have no hope to build the kernel in any way so I do not see how C89 is relevant here anymore. 1 - because it's easier to port to C89/C90 + gnu extensions from C89/C90 than C99 (moving variable declarations back at the beginning of each block is already a pain) 2 - this is related to what I'm doing to my code, it was informational in order to help you do your choice. regards, -- Sylvain
Re: [dev] c++-style comments [was fsbm]
On Thu, 6 Nov 2014 09:34:17 -0800 Louis Santillan lpsan...@gmail.com wrote: There is one case where C++ style comment create a useful feature that I don't believe C style comments are able to replicate. Some might disagree. In a color syntax highlighting editor in a C99 codebase, you can prefix C style comments with C++ style comments and get single character feature enable/disabling. //* Remove first / to disable this block doSomething(); //*/ In a color syntax highlighting editor, doSomething(); takes on normal highlighting when enabled, and takes on comment colored highlighting when disabled. Is this a joke? -- FRIGN d...@frign.de
Re: [dev] c++-style comments [was fsbm]
On 6 November 2014 10:28, Bobby Powers bobbypow...@gmail.com wrote: Hello, Hiltjo Posthuma wrote: - Don't use C++ style comments (//). I personally find C++ style comments more pleasant on the eyes for single-line comments, and they are part of the C99 spec. Can someone explain why they think /* */ sucks less than // ? It doesn't seem like it is for compatibility when st and dwm require C99 anyway. An internet search did not turn up much, apologies if I've missed an obvious link or previous discussion. yours, Bobby My code, my response: While i do vaguely see the benefit of being able to strip all newline characters, I really don't give a shit. I use // because it is easier and faster for me to write, especially while debugging and writing new code. Many compilers who were only C89 or ANSI compliant did in fact allow c99 / c++ style comments anyway Yours Truly, Calvin
Re: [dev] c++-style comments [was fsbm]
It's a joke only if you're laughing. Hey, it's no worse than
stringifying/blobbing a C file [0] (which works well in gcc/clang).
All people have done is game cpp and the standard.
#define STRINGIFY(src) #src
inline const char* Kernels() {
static const char* kernels = STRINGIFY(
#include kernels/util.cl
#include kernels/basic.cl
);
return kernels;
}
[0]
http://stackoverflow.com/questions/6502173/preprocessor-tomfoolery-stringifying-a-include
On Thu, Nov 6, 2014 at 9:45 AM, FRIGN d...@frign.de wrote:
On Thu, 6 Nov 2014 09:34:17 -0800
Louis Santillan lpsan...@gmail.com wrote:
There is one case where C++ style comment create a useful feature that I
don't believe C style comments are able to replicate. Some might disagree.
In a color syntax highlighting editor in a C99 codebase, you can prefix C
style comments with C++ style comments and get single character feature
enable/disabling.
//* Remove first / to disable this block
doSomething();
//*/
In a color syntax highlighting editor, doSomething(); takes on normal
highlighting when enabled, and takes on comment colored highlighting when
disabled.
Is this a joke?
--
FRIGN d...@frign.de
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 06:40:15PM +0100, Sylvain BERTRAND wrote: On Thu, Nov 06, 2014 at 05:09:44PM +, Dimitris Papastamos wrote: On Thu, Nov 06, 2014 at 05:56:55PM +0100, Sylvain BERTRAND wrote: On Thu, Nov 06, 2014 at 03:40:56PM +, Dimitris Papastamos wrote: On Thu, Nov 06, 2014 at 04:38:20PM +0100, Sylvain BERTRAND wrote: On a personnal level, I port some of my C99 projects back to C89, since it seems a C89 compiler is easier to write than a C99 compiler, and some part of my code could go in C89 only project (i.e. the linux kernel). the linux kernel is built with gnu99 iirc. Documentation/HOWTO: The kernel is written using GNU C and the GNU toolchain. While it adheres to the ISO C89 standard, it uses a number of extensions that are not featured in the standard. The kernel is a freestanding C environment, with no reliance on the standard C library, so some portions of the C standard are not supported. Arbitrary long long divisions and floating point are not allowed. It can sometimes be difficult to understand the assumptions the kernel has on the toolchain and the extensions that it uses, and unfortunately there is no definitive reference for them. Please check the gcc info pages (`info gcc`) for some information on them. It uses a *lot* of extensions. If I remember correctly, a significant number of gcc extensions were initially driven by the needs of linux kernel programmers. A C89 only compiler would have no hope to build the kernel in any way so I do not see how C89 is relevant here anymore. 1 - because it's easier to port to C89/C90 + gnu extensions from C89/C90 than C99 (moving variable declarations back at the beginning of each block is already a pain) There's many instances in the kernel code where variables are not declared at the beginning of the function block.
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 6, 2014, at 12:34, Louis Santillan wrote: In a color syntax highlighting editor, doSomething(); takes on normal highlighting when enabled, and takes on comment colored highlighting when disabled. Visually, that's slightly improved over something like #ifdef DEBUG doSomething(); #endif In the editor *I* use, it has comment colored highlighting for #if 0, and for the #else of #if 1, and the same for anything with #if 0 and #if 1 ||.
Re: [dev] c++-style comments [was fsbm]
Hello,
FRIGN wrote:
De gustibus non est disputandum. I personally prefer {/*, */}.
Agreed - taste is taste.
There are many ways to show why {/*, */} sucks less than {//}. Here is
one:
If you take a look at C, everything is block-oriented. The smallest
linguistic entity is ...;, followed by (...) and {...}. The
traditional comments /*...*/ are part of this axiomatic system.
This approach is not line-oriented. Taking preprocessor
directives and includes aside, you can literally strip all newlines
from a given C-source and it would still compile.
Since I'm only interested in writing code that runs on an operating
system with a kernel, there is no time where I would create a binary
from C source code that doesn't #include something. This doesn't seem
to simplify any non-toy compiler implementation.
Given we at suckless work according
to the UNIX-philosophy, and even though UNIX-streams are mostly
line-oriented, a C-source should not depend on non-printable characters
to function properly (except for includes and preprocessor directives).
There is a lot of except and even though in that statement
Moreover, if you write multiline-comments and use {/*, */} while at the
same time using {//} for one-liners can really disrupt code consistency,
and in the end make code harder to maintain and augment.
I happily concede this, and would have no trouble writing /**/
comments in suckless software.
yours,
Bobby
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 06:15:36PM +, Dimitris Papastamos wrote: On Thu, Nov 06, 2014 at 06:40:15PM +0100, Sylvain BERTRAND wrote: On Thu, Nov 06, 2014 at 05:09:44PM +, Dimitris Papastamos wrote: On Thu, Nov 06, 2014 at 05:56:55PM +0100, Sylvain BERTRAND wrote: On Thu, Nov 06, 2014 at 03:40:56PM +, Dimitris Papastamos wrote: On Thu, Nov 06, 2014 at 04:38:20PM +0100, Sylvain BERTRAND wrote: On a personnal level, I port some of my C99 projects back to C89, since it seems a C89 compiler is easier to write than a C99 compiler, and some part of my code could go in C89 only project (i.e. the linux kernel). the linux kernel is built with gnu99 iirc. Documentation/HOWTO: The kernel is written using GNU C and the GNU toolchain. While it adheres to the ISO C89 standard, it uses a number of extensions that are not featured in the standard. The kernel is a freestanding C environment, with no reliance on the standard C library, so some portions of the C standard are not supported. Arbitrary long long divisions and floating point are not allowed. It can sometimes be difficult to understand the assumptions the kernel has on the toolchain and the extensions that it uses, and unfortunately there is no definitive reference for them. Please check the gcc info pages (`info gcc`) for some information on them. It uses a *lot* of extensions. If I remember correctly, a significant number of gcc extensions were initially driven by the needs of linux kernel programmers. A C89 only compiler would have no hope to build the kernel in any way so I do not see how C89 is relevant here anymore. 1 - because it's easier to port to C89/C90 + gnu extensions from C89/C90 than C99 (moving variable declarations back at the beginning of each block is already a pain) There's many instances in the kernel code where variables are not declared at the beginning of the function block. Linus T. does let closed source modules live (even so the GNU GPLv2 gives legal power to open the code, or block binary blob distribution, like what happens with mpeg video or 3D texture compression), moreover the linux kernel is massive... Then I would not be surprised to see code note following Documentation/HOWTO or Documentation/codingstyle. The thing is *I* want *my* code ready to be easier to get into linux and to follow Documentation/HOWTO and Documentation/codingstyle. My 2c and you do whatever with it. cheers, -- Sylvain BERTRAND
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 10:47:28PM +0100, Sylvain BERTRAND wrote: The thing is *I* want *my* code ready to be easier to get into linux and to follow Documentation/HOWTO and Documentation/codingstyle. I will leave you bathe in your fantasies now.
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 10:17:44PM +, Dimitris Papastamos wrote: On Thu, Nov 06, 2014 at 10:47:28PM +0100, Sylvain BERTRAND wrote: The thing is *I* want *my* code ready to be easier to get into linux and to follow Documentation/HOWTO and Documentation/codingstyle. I will leave you bathe in your fantasies now. ok... this is a troll... my bad. kisses all over, -- Sylvain
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 05:56:55PM +0100, Sylvain BERTRAND wrote: I wonder how much of the linux kernel tinycc is able to compile. I don't know about tcc, but there are leftovers[1] of a very unorganized project that tried to compile the Linux kernel with intel icc and IBM XE. There was a slide-deck somewhere that claimed success to compile it with the SUN cc. I think I also remember an efford to do the same with clang. Kind regards, -Alex [1] http://www.linuxdna.com/
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 6, 2014 at 11:44 PM, Sylvain BERTRAND sylw...@legeek.net wrote: On Thu, Nov 06, 2014 at 10:17:44PM +, Dimitris Papastamos wrote: On Thu, Nov 06, 2014 at 10:47:28PM +0100, Sylvain BERTRAND wrote: The thing is *I* want *my* code ready to be easier to get into linux and to follow Documentation/HOWTO and Documentation/codingstyle. I will leave you bathe in your fantasies now. ok... this is a troll... my bad. kisses all over, You are now added to the kickstarter.com assassination objective [1]. From Russia with love, Putin [1] https://www.youtube.com/watch?v=Haypxj24_Uw
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 6, 2014, at 16:47, Sylvain BERTRAND wrote: Linus T. does let closed source modules live (even so the GNU GPLv2 gives legal power to open the code, or block binary blob distribution, like what happens with mpeg video or 3D texture compression), There's a significant amount of debate over what constitutes an 'arms length' interaction between two pieces of code and what makes them effectively a single piece of code. GNU takes the position that sharing the same address space in any way is the latter, and that normal interaction through files/pipes/sockets is the former (because it would be politically inconvenient for them to push too far) so long as it's not a specially defined protocol that only exists for that single pair of programs. The kernel people as far as I know take the position that sharing the same address space is okay so long as they only use certain approved APIs intended for use by modules - and that userspace-kernel interaction via normal system calls is always okay. None of this has been examined by a court.
Re: [dev] c++-style comments [was fsbm]
On Thu, Nov 06, 2014 at 08:34:40PM -0500, random...@fastmail.us wrote: None of this has been examined by a court. It's because Linus T. and many core kernel devs decided not to go to court against closed source modules. The linux GNU GPLv2 has only the syscall exception and does not contain the lesser exception that would allow binary blobs to live below the syscalls. The syscall exception has been in there since the beginning I presume. Adding the lesser exception would be license change. Thus, nvidia ass holes can keep distributing their binary blob for linux, since linux is actually a GNU 'lesser' GPLv2 kernel which in *not* a plain GNU GPVv2. It's a balance of power issue: if linux wants to become a sensible alternative on the desktop, it must have a nvidia driver because they have a huge market share. Then, it was decided to let go... regards, -- Sylvain
