Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #24380 > unrolled thread

How to name a function to indicate that they require calling from a critical section?

Back to article view | Back to comp.lang.c

Contents

  How to name a function to indicate that they require calling from a critical section? celephicus@gmail.com - 2012-08-08 18:55 -0700
    Re: How to name a function to indicate that they require calling from a critical section? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-09 08:31 -0400
    Re: How to name a function to indicate that they require calling from a critical section? "China Blue [Tor], Meersburg" <chine.bleu@yahoo.com> - 2012-08-09 12:24 -0700
      Re: How to name a function to indicate that they require calling from a critical section? Keith Thompson <kst-u@mib.org> - 2012-08-09 13:59 -0700
    Re: How to name a function to indicate that they require calling from a critical section? Andrew Cooper <amc96@cam.ac.uk> - 2012-08-09 21:43 +0100
      Re: How to name a function to indicate that they require calling from a critical section? Keith Thompson <kst-u@mib.org> - 2012-08-09 13:58 -0700
        Re: How to name a function to indicate that they require calling from a critical section? Andrew Cooper <amc96@cam.ac.uk> - 2012-08-09 23:11 +0100
          Re: How to name a function to indicate that they require calling from a critical section? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-09 18:22 -0400
        Re: How to name a function to indicate that they require calling from a critical section? Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 08:37 -0700
          Re: How to name a function to indicate that they require calling from a critical section? Stephen Sprunk <stephen@sprunk.org> - 2012-09-07 16:01 -0500
            Re: How to name a function to indicate that they require calling from a critical section? Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 18:37 -0700
              Re: How to name a function to indicate that they require calling from a critical section? Stephen Sprunk <stephen@sprunk.org> - 2012-09-30 00:17 -0500
                Re: How to name a function to indicate that they require calling from a critical section? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 14:24 -0800
            Re: How to name a function to indicate that they require calling   from a critical section? Ian Collins <ian-news@hotmail.com> - 2012-09-08 13:56 +1200
              Re: How to name a function to indicate that they require calling   from a critical section? Stephen Sprunk <stephen@sprunk.org> - 2012-09-30 13:45 -0500

#24380 — How to name a function to indicate that they require calling from a critical section?

Good programmers know about critical sections, which protect shared resources. Good programmers use descriptive names. I just spent a day tracking down a real-time bug due to me calling a function outside a critical section.

How would you name a function to indicate that it should only be called from within a critical section? Something like doStuff_critical() with the "_critical" telling you the requirement for a critical section. But of course less ugly.

Any ideas?

[toc] | [next] | [standalone]

#24383

On 8/8/2012 9:55 PM, celephicus@gmail.com wrote:
> Good programmers know about critical sections, which protect shared resources. Good programmers use descriptive names. I just spent a day tracking down a real-time bug due to me calling a function outside a critical section.
>
> How would you name a function to indicate that it should only be called from within a critical section? Something like doStuff_critical() with the "_critical" telling you the requirement for a critical section. But of course less ugly.
>
> Any ideas?

     Idea: Pthreads uses names like fputc_unlocked() for a similar
purpose, and you might imitate that.  I don't think the ugliness
of such names should be much of a barrier; you *want* them to jump
out and be difficult to overlook -- even difficult to type, if the
functions should only be called in unusual circumstances.

     But could you do better by reorganizing the program a bit?
By that I mean: In many cases, an "uncritical" piece of the program
calls a function that "goes critical" (acquires a lock, whatever),
does its job, restores normal mode, and returns to the caller, with
its work done and no longer "critical."  If the function's work is
complex enough to be broken down into sub-functions, consider making
those subordinate functions `static' so outsiders cannot call them
directly but can only get at them through the "safe" API.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#24384

In article <12497759-f557-4c9a-a4f4-7bcf177b251d@googlegroups.com>,
 celephicus@gmail.com wrote:

> Good programmers know about critical sections, which protect shared 
> resources. Good programmers use descriptive names. I just spent a day 
> tracking down a real-time bug due to me calling a function outside a critical 
> section.
> 
> How would you name a function to indicate that it should only be called from 
> within a critical section? Something like doStuff_critical() with the 
> "_critical" telling you the requirement for a critical section. But of course 
> less ugly.
> 
> Any ideas?

zephodBeebleBrox_function

-- 
My name Indigo Montoya.      |            Die, Robbie Ferrier! Die!
You flamed my father.        |       I'm whoever you want me to be.
Prepare to be spanked.       |  Annoying Usenet one post at a time.
Stop posting that!           |    At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#24387

"China Blue [Tor], Meersburg" <chine.bleu@yahoo.com> writes:
> In article <12497759-f557-4c9a-a4f4-7bcf177b251d@googlegroups.com>,
>  celephicus@gmail.com wrote:
>
>> Good programmers know about critical sections, which protect shared
>> resources. Good programmers use descriptive names. I just spent a day
>> tracking down a real-time bug due to me calling a function outside a
>> critical section.
>> 
>> How would you name a function to indicate that it should only be
>> called from within a critical section? Something like
>> doStuff_critical() with the "_critical" telling you the requirement
>> for a critical section. But of course less ugly.
>> 
>> Any ideas?
>
> zephodBeebleBrox_function

How does appending "_function" to the name suggest critical sections? Or
did you mean something else?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#24385

On 09/08/2012 02:55, celephicus@gmail.com wrote:
> Good programmers know about critical sections, which protect shared resources. Good programmers use descriptive names. I just spent a day tracking down a real-time bug due to me calling a function outside a critical section.
> 
> How would you name a function to indicate that it should only be called from within a critical section? Something like doStuff_critical() with the "_critical" telling you the requirement for a critical section. But of course less ugly.
> 
> Any ideas?
> 

By and large, Linux and Xen tend to use foo() and __foo(), where __foo()
is the actual implementation, with assumptions about locks etc in the
comments, and foo() is a wrapper which takes the correct lock(s), irq
states etc.

As a result, non-critical sections can call foo() and bar(), while a
larger complicated critical section can take the relevant locks and call
the required __foo() and __bar() functions.

(Although it should be noted that kernel critical sections will probably
differ widely from application level critical sections)

~Andrew

[toc] | [prev] | [next] | [standalone]

#24386

Andrew Cooper <amc96@cam.ac.uk> writes:
> On 09/08/2012 02:55, celephicus@gmail.com wrote:
>> Good programmers know about critical sections, which protect shared
>> resources. Good programmers use descriptive names. I just spent a day
>> tracking down a real-time bug due to me calling a function outside a
>> critical section.
>> 
>> How would you name a function to indicate that it should only be
>> called from within a critical section? Something like
>> doStuff_critical() with the "_critical" telling you the requirement
>> for a critical section. But of course less ugly.
>
> By and large, Linux and Xen tend to use foo() and __foo(), where __foo()
> is the actual implementation, with assumptions about locks etc in the
> comments, and foo() is a wrapper which takes the correct lock(s), irq
> states etc.
>
> As a result, non-critical sections can call foo() and bar(), while a
> larger complicated critical section can take the relevant locks and call
> the required __foo() and __bar() functions.
>
> (Although it should be noted that kernel critical sections will probably
> differ widely from application level critical sections)

Identifiers starting with two underscores, or with an underscore and an
uppercase letter, are reserved to the implementation; if you define such
an identifer yourself, the behavior is undefined.

(The kernel is arguably part of the implementation, and even if it
isn't, it's probably ok for the developers to rely on certain behaviors
that aren't defined by the language standard.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#24389

On 09/08/2012 21:58, Keith Thompson wrote:
> Andrew Cooper <amc96@cam.ac.uk> writes:
>> On 09/08/2012 02:55, celephicus@gmail.com wrote:
>>> Good programmers know about critical sections, which protect shared
>>> resources. Good programmers use descriptive names. I just spent a day
>>> tracking down a real-time bug due to me calling a function outside a
>>> critical section.
>>>
>>> How would you name a function to indicate that it should only be
>>> called from within a critical section? Something like
>>> doStuff_critical() with the "_critical" telling you the requirement
>>> for a critical section. But of course less ugly.
>>
>> By and large, Linux and Xen tend to use foo() and __foo(), where __foo()
>> is the actual implementation, with assumptions about locks etc in the
>> comments, and foo() is a wrapper which takes the correct lock(s), irq
>> states etc.
>>
>> As a result, non-critical sections can call foo() and bar(), while a
>> larger complicated critical section can take the relevant locks and call
>> the required __foo() and __bar() functions.
>>
>> (Although it should be noted that kernel critical sections will probably
>> differ widely from application level critical sections)
> 
> Identifiers starting with two underscores, or with an underscore and an
> uppercase letter, are reserved to the implementation; if you define such
> an identifer yourself, the behavior is undefined.
> 
> (The kernel is arguably part of the implementation, and even if it
> isn't, it's probably ok for the developers to rely on certain behaviors
> that aren't defined by the language standard.)
> 

I doubt anyone could make a functional kernel while strictly adhering to
non UD behaviour.  There is "what the standard states" and "what
basically universally works".

Having said that, because of narrow architecture targets of kernels, you
can perhaps rely substantially more on "what will work" while strictly
being UD.

~Andrew (who had never really pondered this before)

[toc] | [prev] | [next] | [standalone]

#24390

On 8/9/2012 6:11 PM, Andrew Cooper wrote:
> On 09/08/2012 21:58, Keith Thompson wrote:
>> [...]
>> Identifiers starting with two underscores, or with an underscore and an
>> uppercase letter, are reserved to the implementation; if you define such
>> an identifer yourself, the behavior is undefined.
>>
>> (The kernel is arguably part of the implementation, and even if it
>> isn't, it's probably ok for the developers to rely on certain behaviors
>> that aren't defined by the language standard.)
>>
>
> I doubt anyone could make a functional kernel while strictly adhering to
> non UD behaviour.  There is "what the standard states" and "what
> basically universally works".

     If you hadn't said "universally" I'd have agreed with you,
more or less.  But it is *not* universally true that you're
free to start your identifiers with __ and have things "work."
Even if you can get away with the particular set of __xxx you
use today with the particular compiler and options you use today,
you may find yourself in trouble tomorrow when you upgrade to the
next compiler version or invent a new identifier or even #include
a new header.

     Example: Try this in gcc:

	#include <stdio.h>
	static const char *whom(void) {
	    return "World";
	}
	int main(void) {
	    printf("Hello, %s!\n", whom());
	}

Everything working?  Okay, now change the identifier `whom' to
`__attribute__'.


> Having said that, because of narrow architecture targets of kernels, you
> can perhaps rely substantially more on "what will work" while strictly
> being UD.

     Agreed that you can -- indeed, must -- rely on a lot of things
the C language itself does not guarantee.  But adopting a dubious
naming convention (when there are plenty of others available) is
begging for trouble just for the thrill of begging.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#26057

Keith Thompson <kst-u@mib.org> writes:

> Andrew Cooper <amc96@cam.ac.uk> writes:
[snip]
>> By and large, Linux and Xen tend to use foo() and __foo(), where __foo()
>> is the actual implementation, [snip]
>
> Identifiers starting with two underscores, or with an underscore and an
> uppercase letter, are reserved to the implementation; if you define such
> an identifer yourself, the behavior is undefined.
>
> (The kernel is arguably part of the implementation, and even if it
> isn't, it's probably ok for the developers to rely on certain behaviors
> that aren't defined by the language standard.)

The Linux kernel is part of no existing C implementation.  And,
even if it were, it is not part of implementations running on
other operating systems (eg MS windows or MacOS), yet presumably
it's expected to be compileable some such environments, so it's
still breaking the rules regarding reserved identifiers.

Don't get me wrong, it's no big deal that these particular
rules are being broken in this case, but that doesn't mean
the rules aren't being broken.

[toc] | [prev] | [next] | [standalone]

#26084

On 07-Sep-12 10:37, Tim Rentsch wrote:
> Keith Thompson <kst-u@mib.org> writes:
>> (The kernel is arguably part of the implementation, and even if it 
>> isn't, it's probably ok for the developers to rely on certain
>> behaviors that aren't defined by the language standard.)
> 
> The Linux kernel is part of no existing C implementation.

The _running_ kernel is arguably part of the implementation; the kernel
_source being compiled_ is not.

> And, even if it were, it is not part of implementations running on other 
> operating systems (eg MS windows or MacOS), yet presumably it's expected 
> to be compileable some such environments, so it's still breaking the 
> rules regarding reserved identifiers.

The Linux kernel is only expected to be compilable by GCC, and successfully
compiling the Linux kernel is a gate in the GCC release process, so the two
are intimately tied together.

I would expect the same of Windows and MSVC, etc.  Kernels are special.

> Don't get me wrong, it's no big deal that these particular rules are 
> being broken in this case, but that doesn't mean the rules aren't being 
> broken.

In such a case, the normal rules are simply not relevant.

OTOH, that also means that one should always be careful before using kernel
source as an example of how to write non-kernel source.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

#26112

Stephen Sprunk <stephen@sprunk.org> writes:

> On 07-Sep-12 10:37, Tim Rentsch wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>> (The kernel is arguably part of the implementation, and even if it 
>>> isn't, it's probably ok for the developers to rely on certain
>>> behaviors that aren't defined by the language standard.)
>> 
>> The Linux kernel is part of no existing C implementation.
>
> The _running_ kernel is arguably part of the implementation;

You mean it's arguably part of _an_ implementation.  I will
take up this question further on.

> the kernel _source being compiled_ is not.
>
>> And, even if it were, it is not part of implementations running on other 
>> operating systems (eg MS windows or MacOS), yet presumably it's expected 
>> to be compileable some such environments, so it's still breaking the 
>> rules regarding reserved identifiers.
>
> The Linux kernel is only expected to be compilable by GCC,

Doesn't change my point, since GCC runs on systems besides
Linux.

> and successfully compiling the Linux kernel is a gate in the
> GCC release process, so the two are intimately tied together.

That doesn't make Linux part of a gcc implementation, any more
than a requirement for a successful compilation of 'rogue' would
make 'rogue' part of gcc implementations.

> I would expect the same of Windows and MSVC, etc.  Kernels are
> special.

Kernels generally are more dependent on their compilation
environment than other programs.  From a compiler's point
of view though they are still just programs.

>> Don't get me wrong, it's no big deal that these particular
>> rules are being broken in this case, but that doesn't mean the
>> rules aren't being broken.
>
> In such a case, the normal rules are simply not relevant.

The rules are relevant precisely because the kernel must
ensure that the rules it chooses to violate won't be
messed up by any implementation-reserved decisions made
by the compiler in question.  If the kernel didn't break
any rules, then it wouldn't matter which compiler is
used to compile it;  it's because the kernel _does_ break
rules that it needs to be choosy about which compilers
it uses.  What I think you mean is that, because the
kernel is compiled with a compiler that doesn't exhibit
destructive interference over the rules the kernel does
break, breaking those rules does not have any negative
effects;  and certainly that is true (by definition
it would have to be).

> OTOH, that also means that one should always be careful before
> using kernel source as an example of how to write non-kernel
> source.

I agree with that, but I think that's more an artifact of
expecting certain definitions of implementation-defined and
implementation-dependent behavior than it is of being a kernel.
Kernels are more prone to rely on those things than most
programs;  but so also are many or most programs that run
on bare hardware, and certainly not all of those are kernels.

On the earlier question of whether Linux (or any typical modern
operating system) is part of a C implementations --

Paragraph 1 of section 5 says

    An implementation translates C source files and executes C
    programs in two data-processing-system environments, which
    will be called the /translation environment/ and the
    /execution environment/ in this International Standard.

Paragraph 2 of section 1 says

    This International Standard does not specify

        [...other items...]

      . all minimal requirements of a data-processing system that
        is capable of supporting a conforming implementation.

My argument is that a running Linux kernel supplies an execution
environment (and perhaps also a translation environment), which
under the descriptions in sections 1 and 5 is a data-processing
system, and as such these /support/ conforming implementations but
are not themselves /part of/ conforming implementations.  The
Standard draws a distinct boundary between the two; and conventional
operating systems are clearly on the non-implementation side of that
boundary.

[toc] | [prev] | [next] | [standalone]

#26851

On 07-Sep-12 20:37, Tim Rentsch wrote:
> Stephen Sprunk <stephen@sprunk.org> writes:
>> On 07-Sep-12 10:37, Tim Rentsch wrote:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> (The kernel is arguably part of the implementation, and even if
>>>> it isn't, it's probably ok for the developers to rely on
>>>> certain behaviors that aren't defined by the language
>>>> standard.)
>>> 
>>> The Linux kernel is part of no existing C implementation.
>> 
>> The _running_ kernel is arguably part of the implementation;
> 
> You mean it's arguably part of _an_ implementation.  I will take up
> this question further on.

I was assuming the context of compiling the Linux kernel on a running
Linux system.  Obviously, if you're compiling the Linux kernel with a
cross-compiler running on some other OS, then the Linux kernel would not
be part of the implementation.

My point was that it's not the kernel source that was being claimed to
be part of the implementation.

>> the kernel _source being compiled_ is not.
>> 
>>> And, even if it were, it is not part of implementations running
>>> on other operating systems (eg MS windows or MacOS), yet
>>> presumably it's expected to be compileable some such
>>> environments, so it's still breaking the rules regarding reserved
>>> identifiers.
>> 
>> The Linux kernel is only expected to be compilable by GCC,
> 
> Doesn't change my point, since GCC runs on systems besides Linux.

True, except that it undercuts the justification for your point.  If the
Linux kernel is only expected to be compilable by GCC, then it is free
to take advantage of GCC's implementation-defined behavior--and that is
exactly what started this discussion.

>> and successfully compiling the Linux kernel is a gate in the GCC
>> release process, so the two are intimately tied together.
> 
> That doesn't make Linux part of a gcc implementation, any more than a
> requirement for a successful compilation of 'rogue' would make
> 'rogue' part of gcc implementations.
> 
>> I would expect the same of Windows and MSVC, etc.  Kernels are 
>> special.
> 
> Kernels generally are more dependent on their compilation environment
> than other programs.  From a compiler's point of view though they are
> still just programs.

That depends.  When GCC has flags (eg. -cmodel=kernel) to tell the
compiler to use a special mode only for kernels, that seems to imply
kernels are not "just programs."

Also, a few years ago GCC added an optimization that _only_ broke
kernels: it removed null pointer checks after a pointer had been
dereferenced on the assumption that if the pointer had been null,
execution could not have continued.  That assumption does not hold in
kernel mode, though, which resulted in a security vulnerability in the
Linux kernel.  Kernels _are_ different in practice, not just theory.

>>> Don't get me wrong, it's no big deal that these particular rules
>>> are being broken in this case, but that doesn't mean the rules
>>> aren't being broken.
>> 
>> In such a case, the normal rules are simply not relevant.
> 
> The rules are relevant precisely because the kernel must ensure that
> the rules it chooses to violate won't be messed up by any
> implementation-reserved decisions made by the compiler in question.

... unless the implementation has made an explicit statement that it
will not violate any assumptions the kernel makes, as in the case of GCC
with respect to the Linux kernel.  (Including, for instance, the
assumption that dereferencing a null pointer has well-defined behavior.)

Note that this does _not_ apply to other kernels that may be compiled
with GCC, in which case your point would be valid.

> If the kernel didn't break any rules, then it wouldn't matter which
> compiler is used to compile it;  it's because the kernel _does_
> break rules that it needs to be choosy about which compilers it uses.

True, but nobody seems to care about that.

Well, Intel seems to have cared, to the point that being able to compile
the Linux kernel was considered a "must have" for ICC to be viable in
the Linux market.  That wouldn't have been such a big deal if the kernel
didn't take advantage of--or dictate--GCC's peculiarities.

> What I think you mean is that, because the kernel is compiled with a
> compiler that doesn't exhibit destructive interference over the rules
> the kernel does break, breaking those rules does not have any
> negative effects;  and certainly that is true (by definition it would
> have to be).

I'm not sure what you mean here.

>> OTOH, that also means that one should always be careful before 
>> using kernel source as an example of how to write non-kernel 
>> source.
> 
> I agree with that, but I think that's more an artifact of expecting
> certain definitions of implementation-defined and 
> implementation-dependent behavior than it is of being a kernel. 
> Kernels are more prone to rely on those things than most programs;
> but so also are many or most programs that run on bare hardware, and
> certainly not all of those are kernels.

That leads to debating what we're really referring to by the term
"kernel", since I doubt we're really restricting it to just OS kernels
but rather any software that runs directly on the hardware without any
intermediary.

> My argument is that a running Linux kernel supplies an execution 
> environment (and perhaps also a translation environment), which under
> the descriptions in sections 1 and 5 is a data-processing system, and
> as such these /support/ conforming implementations but are not
> themselves /part of/ conforming implementations.

Fair enough.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

#29436

Stephen Sprunk <stephen@sprunk.org> writes:

> On 07-Sep-12 20:37, Tim Rentsch wrote:
>> Stephen Sprunk <stephen@sprunk.org> writes:
>>> On 07-Sep-12 10:37, Tim Rentsch wrote:
>>>> Keith Thompson <kst-u@mib.org> writes:
>>>>> (The kernel is arguably part of the implementation, and even if
>>>>> it isn't, it's probably ok for the developers to rely on
>>>>> certain behaviors that aren't defined by the language
>>>>> standard.)
>>>> 
>>>> The Linux kernel is part of no existing C implementation.
>>> 
>>> The _running_ kernel is arguably part of the implementation;
>> 
>> You mean it's arguably part of _an_ implementation.  I will take up
>> this question further on.
>
> I was assuming the context of compiling the Linux kernel on a running
> Linux system.  Obviously, if you're compiling the Linux kernel with a
> cross-compiler running on some other OS, then the Linux kernel would not
> be part of the implementation.
>
> My point was that it's not the kernel source that was being claimed to
> be part of the implementation.
>
>>> the kernel _source being compiled_ is not.
>>> 
>>>> And, even if it were, it is not part of implementations running
>>>> on other operating systems (eg MS windows or MacOS), yet
>>>> presumably it's expected to be compileable some such
>>>> environments, so it's still breaking the rules regarding reserved
>>>> identifiers.
>>> 
>>> The Linux kernel is only expected to be compilable by GCC,
>> 
>> Doesn't change my point, since GCC runs on systems besides Linux.
>
> True, except that it undercuts the justification for your point.  If the
> Linux kernel is only expected to be compilable by GCC, then it is free
> to take advantage of GCC's implementation-defined behavior--and that is
> exactly what started this discussion.
>
>>> and successfully compiling the Linux kernel is a gate in the GCC
>>> release process, so the two are intimately tied together.
>> 
>> That doesn't make Linux part of a gcc implementation, any more than a
>> requirement for a successful compilation of 'rogue' would make
>> 'rogue' part of gcc implementations.
>> 
>>> I would expect the same of Windows and MSVC, etc.  Kernels are 
>>> special.
>> 
>> Kernels generally are more dependent on their compilation environment
>> than other programs.  From a compiler's point of view though they are
>> still just programs.
>
> That depends.  When GCC has flags (eg. -cmodel=kernel) to tell the
> compiler to use a special mode only for kernels, that seems to imply
> kernels are not "just programs."
>
> Also, a few years ago GCC added an optimization that _only_ broke
> kernels: it removed null pointer checks after a pointer had been
> dereferenced on the assumption that if the pointer had been null,
> execution could not have continued.  That assumption does not hold in
> kernel mode, though, which resulted in a security vulnerability in the
> Linux kernel.  Kernels _are_ different in practice, not just theory.
>
>>>> Don't get me wrong, it's no big deal that these particular rules
>>>> are being broken in this case, but that doesn't mean the rules
>>>> aren't being broken.
>>> 
>>> In such a case, the normal rules are simply not relevant.
>> 
>> The rules are relevant precisely because the kernel must ensure that
>> the rules it chooses to violate won't be messed up by any
>> implementation-reserved decisions made by the compiler in question.
>
> ... unless the implementation has made an explicit statement that it
> will not violate any assumptions the kernel makes, as in the case of GCC
> with respect to the Linux kernel.  (Including, for instance, the
> assumption that dereferencing a null pointer has well-defined behavior.)
>
> Note that this does _not_ apply to other kernels that may be compiled
> with GCC, in which case your point would be valid.
>
>> If the kernel didn't break any rules, then it wouldn't matter which
>> compiler is used to compile it;  it's because the kernel _does_
>> break rules that it needs to be choosy about which compilers it uses.
>
> True, but nobody seems to care about that.
>
> Well, Intel seems to have cared, to the point that being able to compile
> the Linux kernel was considered a "must have" for ICC to be viable in
> the Linux market.  That wouldn't have been such a big deal if the kernel
> didn't take advantage of--or dictate--GCC's peculiarities.
>
>> What I think you mean is that, because the kernel is compiled with a
>> compiler that doesn't exhibit destructive interference over the rules
>> the kernel does break, breaking those rules does not have any
>> negative effects;  and certainly that is true (by definition it would
>> have to be).
>
> I'm not sure what you mean here.
>
>>> OTOH, that also means that one should always be careful before 
>>> using kernel source as an example of how to write non-kernel 
>>> source.
>> 
>> I agree with that, but I think that's more an artifact of expecting
>> certain definitions of implementation-defined and 
>> implementation-dependent behavior than it is of being a kernel. 
>> Kernels are more prone to rely on those things than most programs;
>> but so also are many or most programs that run on bare hardware, and
>> certainly not all of those are kernels.
>
> That leads to debating what we're really referring to by the term
> "kernel", since I doubt we're really restricting it to just OS kernels
> but rather any software that runs directly on the hardware without any
> intermediary.
>
>> My argument is that a running Linux kernel supplies an execution 
>> environment (and perhaps also a translation environment), which under
>> the descriptions in sections 1 and 5 is a data-processing system, and
>> as such these /support/ conforming implementations but are not
>> themselves /part of/ conforming implementations.
>
> Fair enough.

Rather than trying to respond point-by-point, let me summarize.

What I think you're saying is that, for all practical purposes,
gcc is effectively part of the Linux kernel;  the Linux kernel
depends so much on gcc for its compilation that the kernel
as a runnable entity basically doesn't exist without gcc.

What I'm trying to say is that, even granting that gcc is part
of the Linux kernel, the Linux kernel is not part of any gcc
implementation.  And I think you agreed to that right at the
end there.

As long as you agree with those last two paragraphs, I think
we're all good.

[toc] | [prev] | [next] | [standalone]

#26113 — Re: How to name a function to indicate that they require calling from a critical section?

On 09/ 8/12 09:01 AM, Stephen Sprunk wrote:
> On 07-Sep-12 10:37, Tim Rentsch wrote:
>> Keith Thompson<kst-u@mib.org>  writes:
>>> (The kernel is arguably part of the implementation, and even if it
>>> isn't, it's probably ok for the developers to rely on certain
>>> behaviors that aren't defined by the language standard.)
>>
>> The Linux kernel is part of no existing C implementation.
>
> The _running_ kernel is arguably part of the implementation; the kernel
> _source being compiled_ is not.
>
>> And, even if it were, it is not part of implementations running on other
>> operating systems (eg MS windows or MacOS), yet presumably it's expected
>> to be compileable some such environments, so it's still breaking the
>> rules regarding reserved identifiers.
>
> The Linux kernel is only expected to be compilable by GCC, and successfully
> compiling the Linux kernel is a gate in the GCC release process, so the two
> are intimately tied together.
>
> I would expect the same of Windows and MSVC, etc.  Kernels are special.

Not necessarily. One of the early tasks when the Solaris kernel was 
open-sourced was to get it to compile cleanly with gcc as well as the 
native compiler.  This took a while, but in the process removed a lot of 
cruft from the source.  Just like any other code base, being able to 
compile with more than one compiler is a good way to improve and 
maintain code quality.  From my occasional exposure to it, my impression 
is the Linux kernel is a lost cause when it comes to compiler portability!

Due to their size and reliance on high levels of optimisation, kernels 
are more susceptible than most applications to compiler bugs.  This 
should be seen as an opportunity to improve compiler quality rather than 
a direct coupling.

>> Don't get me wrong, it's no big deal that these particular rules are
>> being broken in this case, but that doesn't mean the rules aren't being
>> broken.
>
> In such a case, the normal rules are simply not relevant.
>
> OTOH, that also means that one should always be careful before using kernel
> source as an example of how to write non-kernel source.

See above.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#26893 — Re: How to name a function to indicate that they require calling from a critical section?

On 07-Sep-12 20:56, Ian Collins wrote:
> On 09/ 8/12 09:01 AM, Stephen Sprunk wrote:
>> On 07-Sep-12 10:37, Tim Rentsch wrote:
>>> Keith Thompson<kst-u@mib.org>  writes:
>>> And, even if [the kernel] were [part of the implementation], it
>>> is not part of implementations running on other operating systems
>>> (eg MS windows or MacOS), yet presumably it's expected to be
>>> compileable some such environments, so it's still breaking the
>>> rules regarding reserved identifiers.
>> 
>> The Linux kernel is only expected to be compilable by GCC, and 
>> successfully compiling the Linux kernel is a gate in the GCC 
>> release process, so the two are intimately tied together.
>> 
>> I would expect the same of Windows and MSVC, etc.  Kernels are 
>> special.
> 
> Not necessarily. One of the early tasks when the Solaris kernel was 
> open-sourced was to get it to compile cleanly with gcc as well as the
> native compiler.  This took a while, but in the process removed a lot
> of cruft from the source.  Just like any other code base, being able
> to compile with more than one compiler is a good way to improve and
> maintain code quality.

I agree that making code portable tends to increase quality, but that's
not really the point.

> From my occasional exposure to it, my impression is the Linux kernel
> is a lost cause when it comes to compiler portability!

Probably.  I'll note that the ICC folks chose to copy GCC's "features"
rather than change the Linux kernel source itself to be more portable.
I don't know what drove that decision, nor am I qualified to judge
whether the kernel developers are justified in the use of said
"features" in the first place, since they're obviously more skilled than
I am.

> Due to their size and reliance on high levels of optimisation, 
> kernels are more susceptible than most applications to compiler
> bugs.

I don't think it's bugs per se but that kernels, by their nature, tend
to rely on behaviors that the Standard does not (and cannot) guarantee,
which means they become tied to the particular compiler(s) used to
compile them.

IMHO, the ability to write both portable and non-portable code in the
same language is one of C's strengths--and a reason for its enduring
success.  However, it takes discipline to segregate the two types of
code, which apparently many people (including those who write books)
seem to be lacking.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web