* Request for warnings on implicit bool to int conversions @ 2012-03-27 22:43 mathog 2012-03-28 1:00 ` Paolo Carlini 2012-03-28 9:00 ` Franz Sirl 0 siblings, 2 replies; 15+ messages in thread From: mathog @ 2012-03-27 22:43 UTC (permalink / raw) To: gcc The C99 bool data type, and the similar type in C++, currently (v 4.5.2) do not generate warnings for any of these sorts of operations: bool b; b = 3; b++; b += 2; if(b == 3) etc. This can lead to a lot of hidden mischief because a variable declared far away may look like an integer, but it acts like a bool. It would be nice if there was a -Wimplicit_bool that was enabled in -Wall which complained about these sorts of operations. In particular it would warn any time a bool was implicitly promoted to an int. This issued was recently discussed in newsgroup comp.lang.c under the subject: c99 and the lack of warnings when int operations are applied to a bool Thank you, David Mathog mathog@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Request for warnings on implicit bool to int conversions 2012-03-27 22:43 Request for warnings on implicit bool to int conversions mathog @ 2012-03-28 1:00 ` Paolo Carlini 2012-03-28 1:19 ` Gabriel Dos Reis 2012-03-28 9:00 ` Franz Sirl 1 sibling, 1 reply; 15+ messages in thread From: Paolo Carlini @ 2012-03-28 1:00 UTC (permalink / raw) To: mathog; +Cc: gcc Hi, > It would be nice if there was a > > -Wimplicit_bool > > that was enabled in -Wall which complained about these sorts of > operations. In particular > it would warn any time a bool was implicitly promoted to an int. first blush your message should be a Bugzilla PR, this way the request doesn't risk to get lost and knowledgeable people could carefully analyze it in due course. Thanks, Paolo. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Request for warnings on implicit bool to int conversions 2012-03-28 1:00 ` Paolo Carlini @ 2012-03-28 1:19 ` Gabriel Dos Reis 2012-03-28 2:21 ` Russ Allbery 0 siblings, 1 reply; 15+ messages in thread From: Gabriel Dos Reis @ 2012-03-28 1:19 UTC (permalink / raw) To: mathog; +Cc: gcc > Hi, >> >> It would be nice if there was a >> >> -Wimplicit_bool >> >> that was enabled in -Wall which complained about these sorts of >> operations. In particular >> it would warn any time a bool was implicitly promoted to an int. > I am trying to understand what the real issue is here. Do you want -Wimplicit-char-to-int to? -Wimplicit-short-to-int? If not, why? where to stop? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Request for warnings on implicit bool to int conversions 2012-03-28 1:19 ` Gabriel Dos Reis @ 2012-03-28 2:21 ` Russ Allbery 2012-03-28 2:30 ` Gabriel Dos Reis 2012-03-28 19:32 ` [bool wrapping] " Michael Witten 0 siblings, 2 replies; 15+ messages in thread From: Russ Allbery @ 2012-03-28 2:21 UTC (permalink / raw) To: gcc Gabriel Dos Reis <gdr@integrable-solutions.net> writes: > I am trying to understand what the real issue is here. Do you want > -Wimplicit-char-to-int to? -Wimplicit-short-to-int? If not, why? > where to stop? I think it's more about conversion *to* bool than from bool, and it catches places where code has been partly converted to bool (generally because it predated C99) but the error conversion wasn't done properly. For example, while returning true or false is common, returning 0 or -1 as a boolean return value where 0 is success is also common (as with UNIX library interfaces). If someone messes up such a conversion and has a: status = -1; somewhere, they get entirely the wrong result if status becomes a bool. This warning would pick up cases like that. The warnings about doing things like: bool b = true; b++; b += 3; are somewhat akin to the warnings about doing arithmetic on void * pointers -- code like that is possibly a sign that there's something flawed with the algorithm and it should be rewritten to treat booleans as actual booleans. (For example, b++ could easily wrap, and unexpectedly fast depending on the size of bool on a platform.) -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Request for warnings on implicit bool to int conversions 2012-03-28 2:21 ` Russ Allbery @ 2012-03-28 2:30 ` Gabriel Dos Reis 2012-03-28 2:40 ` Russ Allbery 2012-03-28 19:32 ` [bool wrapping] " Michael Witten 1 sibling, 1 reply; 15+ messages in thread From: Gabriel Dos Reis @ 2012-03-28 2:30 UTC (permalink / raw) To: Russ Allbery; +Cc: gcc On Tue, Mar 27, 2012 at 9:20 PM, Russ Allbery <rra@stanford.edu> wrote: > Gabriel Dos Reis <gdr@integrable-solutions.net> writes: > >> I am trying to understand what the real issue is here. Do you want >> -Wimplicit-char-to-int to? -Wimplicit-short-to-int? If not, why? >> where to stop? > > I think it's more about conversion *to* bool than from bool, I can easily see why an implicit conversion from int to bool might cause a problem, even if that is what the language standard mandates -- just look at the most common misuses of strcmp. But, that is not what the proposer requested, which got me scratching my head. -- Gaby ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Request for warnings on implicit bool to int conversions 2012-03-28 2:30 ` Gabriel Dos Reis @ 2012-03-28 2:40 ` Russ Allbery 2012-03-28 2:48 ` Russ Allbery 0 siblings, 1 reply; 15+ messages in thread From: Russ Allbery @ 2012-03-28 2:40 UTC (permalink / raw) To: gcc Gabriel Dos Reis <gdr@integrable-solutions.net> writes: > I can easily see why an implicit conversion from int to bool might cause > a problem, even if that is what the language standard mandates -- just > look at the most common misuses of strcmp. But, that is not what the > proposer requested, which got me scratching my head. Yeah. But I suspect it was a mistaken statement. The subject line from the referenced comp.lang.c thread was: c99 and the lack of warnings when int operations are applied to a bool which I think is best caught by the conversion *to* bool when the result is stored, rather than the conversion *from* bool to perform the operation. I could see the other direction being marginally helpful in catching people adding bools together, which may not make a lot of sense, but it doesn't seem as likely to cause bugs. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Request for warnings on implicit bool to int conversions 2012-03-28 2:40 ` Russ Allbery @ 2012-03-28 2:48 ` Russ Allbery 0 siblings, 0 replies; 15+ messages in thread From: Russ Allbery @ 2012-03-28 2:48 UTC (permalink / raw) To: gcc Russ Allbery <rra@stanford.edu> writes: > Yeah. But I suspect it was a mistaken statement. The subject line from > the referenced comp.lang.c thread was: > c99 and the lack of warnings when int operations are applied to a bool > which I think is best caught by the conversion *to* bool when the result > is stored, rather than the conversion *from* bool to perform the > operation. I've just briefly reviewed the thread, and it was about both, including some discussion of warning about any operation that promotes a bool to some other integer type, on the grounds that a bool would ideally be treated as a special enumeration that didn't behave like an integer. (With others pointing out that that isn't the programming language that we have, as appealing as it might have been if designing C from scratch.) But I think most of the *practical* problems would be caught by warning about the implicit integer conversion to bool, if there's a way to wedge that warning into the language. (I suspect it might be hard because the integer conversion may happen under the hood in lots of places that people don't expect, but I don't know much about the internals.) -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bool wrapping] Request for warnings on implicit bool to int conversions 2012-03-28 2:21 ` Russ Allbery 2012-03-28 2:30 ` Gabriel Dos Reis @ 2012-03-28 19:32 ` Michael Witten 2012-03-28 20:30 ` mathog 1 sibling, 1 reply; 15+ messages in thread From: Michael Witten @ 2012-03-28 19:32 UTC (permalink / raw) To: Russ Allbery; +Cc: Gabriel Dos Reis, Paolo Carlini, David Mathog, gcc On Tue, 27 Mar 2012 19:20:52 -0700, Russ Allbery wrote: > (For example, b++ could easily wrap, and unexpectedly fast > depending on the size of bool on a platform.) Actually, it would appear that a bool (or a _Bool) can't wrap on increment, but it CAN wrap on decrement (and strangely, when the operand is a bool, C++ not only deprecates the prefix and postfix `++' operators, but also forbids the prefix and postfix `--' operators; this is particularly strange given that similar semantics are still to be had with the `+=' and `-=' compound assignments). I'm going to deal with the prefix operators rather than the postfix operators, in order to concentrate on the value that is newly assigned to the variable in question. Firstly, the C++ standard is very explicit and concise. According to C++11.5.3.2 "Increment and decrement": 1 The operand of prefix ++ is modified by adding 1, or set to true if it is bool (this use is deprecated). The operand shall be a modifiable lvalue. The type of the operand shall be an arithmetic type or a pointer to a completely-defined object type. The result is the updated operand; it is an lvalue, and it is a bit-field if the operand is a bit-field. If x is not of type bool, the expression ++x is equivalent to x+=1... 2 The operand of prefix -- is modified by subtracting 1. The operand shall not be of type bool. The requirements on the operand of prefix -- and the properties of its result are otherwise the same as those of prefix ++... As for C99, indulge me for a moment. According to C99.6.5.3.1 "Prefix increment and decrement operators": ... 2 The value of the operand of the prefix ++ operator is incremented. The result is the new value of the operand after incrementation. The expression ++E is equivalent to (E+=1). See the discussions of additive operators and compound assignment for information on constraints, types, side effects, and conversions and the effects of operations on pointers. ... and according to C99.6.5.16.2 "Compound Assignment": ... 3 A compound assignment of the form E1 op= E2 differs from the simple assignment expression E1 = E1 op (E2) only in that the lvalue E1 is evaluated only once. and according to C99.6.5.6 "Additive operators": ... 2 For addition, either both operands shall have arithmetic type, or one operand shall be a pointer to an object type and the other shall have integer type. (Incrementing is equivalent to adding 1.) ... 4 If both operands have arithmetic type, the usual arithmetic conversions are performed on them. 5 The result of the binary + operator is the sum of the operands. ... and according to C99.6.2.5 "Types": ... 6 ... The type _Bool and the unsigned integer types that correspond to the standard signed integer types are the standard unsigned integer types... The standard and extended unsigned integer types are collectively called unsigned integer types. ... 17 The type char, the signed and unsigned integer types, and the enumerated types are collectively called integer types... 18 Integer and floating types are collectively called arithmetic types. ... and according to C99.6.3.1.8 "Usual arithmetic conversions": 1 ... Otherwise, the integer promotions are performed on both operands. Then the following rules are applied to the promoted operands: If both operands have the same type, then no further conversion is needed. ... ... ... and according to C99.6.3.1.1 "Boolean, characters, and integers" 2 ... If an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions... and according to C99.6.3.1.2 "Boolean type": 1 When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1. and according to C99.7.16 "Boolean type and values <stdbool.h>": 1 The header <stdbool.h> defines four macros. 2 The macro bool expands to _Bool. ... So, the prefix `++' operator expression in the following: bool b = 1; ++b; should assign to `b' the value of the following expression: (bool)((int)b + (int)1) (bool)((int)1 + (int)1) (bool)2 1 That is, the value of `b' should remain `1', which is corroborated when the following program: #include <stdbool.h> int main(void) { bool b = 1; for (;;) ++b; } is compiled with: gcc -std=c99 -pedantic -Wall -O0 -fdump-tree-gimple d.c thereby yield the following GIMPLE representation: main () { int D.1090; { _Bool b; b = 1; <D.1088>: b = 1; goto <D.1088>; } D.1090 = 0; return D.1090; } As you can see, the loop simply keeps assigning to `b' the value `1': <D.1088>: b = 1; goto <D.1088>; As for decrementing a _Bool, according to C99.6.5.3.1 "Prefix increment and decrement operators": The prefix -- operator is analogous to the prefix ++ operator, except that the value of the operand is decremented. So, the prefix `--' operator expression in the following: #include <stdbool.h> bool b = 0; --b; should assign to `b' the value of the following expression: (bool)((int)b - (int)1) (bool)((int)0 - (int)1) (bool)-1 1 That is, the value of `b' can wrap on decrement, which is corroborated when the following program: #include <stdbool.h> int main(void) { bool b = 0; for (;;) --b; } is compiled with: gcc -std=c99 -pedantic -Wall -O0 -fdump-tree-gimple d.c thereby yield the following GIMPLE representation: main () { int D.1090; { _Bool b; b = 0; <D.1088>: b = !b; goto <D.1088>; } D.1090 = 0; return D.1090; } As you can see, the loop simply keeps assigning to `b' the logical negation of `b': <D.1088>: b = !b; goto <D.1088>; Similar arguments can be made for `b+=1' and `b-=1' (even for C++); however, the GIMPLE representation is sometimes not as optimized: For `b+=1' (and similarly for `b-=1'), gcc produces the following more general computation: <D.1088>: D.1090 = (int) b; D.1091 = D.1090 + 1; b = D.1091 != 0; goto <D.1088>; Also, while g++ does the simple logical negation for `b-=1', it instead forgos a simple assignment of `1' in favor of the following bizarre gymnastics for `b+=1': <D.983>: D.984 = (int) b; b = D.984 != -1; goto <D.983>; Maybe there's room for a patch? Anyway, I'm done with my mental pleasuring for the day. Ta ta! Michael Witten ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bool wrapping] Request for warnings on implicit bool to int conversions 2012-03-28 19:32 ` [bool wrapping] " Michael Witten @ 2012-03-28 20:30 ` mathog 2012-03-28 22:21 ` Michael Witten 2012-03-28 22:28 ` Michael Witten 0 siblings, 2 replies; 15+ messages in thread From: mathog @ 2012-03-28 20:30 UTC (permalink / raw) To: gcc On 28-Mar-2012 12:18, Michael Witten wrote: Wow, that was thorough! The behavior of b++ vs. b-- was interesting, but is yet one more reason why the warning is needed. Since b-- is equivalent to !b, and b++ is equivalent to 1, if that action is intended, there is no reason to use either the increment or decrement operators on a bool. > gcc -std=c99 -pedantic -Wall -O0 -fdump-tree-gimple d.c That's a trick worth knowing. Thanks! Ran that on a test program and in every case but one there was an implicit (int) b on sections of code which I though should generate warnings. (Math ops on bools, comparison operations of bool with ints.) The one exception in that little program was: b=2; which came out as b=1; In that case the compiler must have performed an implicit 1 = (bool) 2 Also these forms all generated implicit int conversions if(b==1) if(b==2) if(b==0) whereas if(b) did not. So let's turn this around. If the compiler warned on all implicit conversions of bool <-> int, what program lines would it warn on that it shouldn't? It would warn on: if(b==1) if(b==0) but I would argue that line is inappropriate for a bool type, and should be written as: if(b) With two bool variables, this also did not generate an implicit conversion (and so would not warn, which is appropriate): if(b1 || b2) Whereas this less preferred form would have generated an implicit (int) [and a well deserved warning] if(b1 + b2) Regards, David Mathog mathog@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bool wrapping] Request for warnings on implicit bool to int conversions 2012-03-28 20:30 ` mathog @ 2012-03-28 22:21 ` Michael Witten 2012-03-28 22:52 ` mathog 2012-03-28 22:28 ` Michael Witten 1 sibling, 1 reply; 15+ messages in thread From: Michael Witten @ 2012-03-28 22:21 UTC (permalink / raw) To: mathog; +Cc: gcc On Wed, Mar 28, 2012 at 20:30, mathog <mathog@caltech.edu> wrote: > Since b-- is equivalent to [assigning] !b, > and b++ is equivalent to [assigning] 1, if > that action is intended, there is no reason > to use either the increment or decrement > operators on a bool. However, it seems to me that toggling the value with the idiom: --b; is aesthetically preferable to the more elaborate: b = !b; In fact, I've seen at least one person make this complaint in freenode's ##c++ IRC channel. Given the potential usefulness of `--b' and the relative uselessness of `++b', it would seem more practical for the C++ standard to have deprecated (if not allowed) `--b' and instead forbidden `++b' (rather than the other way around). ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bool wrapping] Request for warnings on implicit bool to int conversions 2012-03-28 22:21 ` Michael Witten @ 2012-03-28 22:52 ` mathog 2012-03-29 10:29 ` David Brown 0 siblings, 1 reply; 15+ messages in thread From: mathog @ 2012-03-28 22:52 UTC (permalink / raw) To: gcc On 28-Mar-2012 15:20, Michael Witten wrote: > However, it seems to me that toggling the value with the idiom: > > --b; > > is aesthetically preferable to the more elaborate: > > b = !b; Aesthetically, not logically. Neither of these makes the least bit of sense: one less than False one less than True A better solution for the aesthetics would have been (it is a bit late now) to implement the missing unary negation operator: !!b; //T->F, F->T That operator would save even more program characters for the other int types, where it would be equivalent to: (i==0 ? 1 : 0); Regards, David Mathog mathog@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bool wrapping] Request for warnings on implicit bool to int conversions 2012-03-28 22:52 ` mathog @ 2012-03-29 10:29 ` David Brown 2012-03-29 17:49 ` mathog 0 siblings, 1 reply; 15+ messages in thread From: David Brown @ 2012-03-29 10:29 UTC (permalink / raw) To: mathog; +Cc: gcc On 29/03/2012 00:52, mathog wrote: > On 28-Mar-2012 15:20, Michael Witten wrote: > >> However, it seems to me that toggling the value with the idiom: >> >> --b; >> >> is aesthetically preferable to the more elaborate: >> >> b = !b; > > Aesthetically, not logically. Neither of these makes the least bit of > sense: > > one less than False > one less than True > > A better solution for the aesthetics would have been (it is a bit late > now) to implement the missing unary negation operator: > > !!b; //T->F, F->T > You can't do that, because "!!" is already a useful operator on integers - it turns anything non-zero into 1 while leaving 0 alone, and is effectively an "int to bool" conversion operator. > That operator would save even more program characters for the other int > types, where it would be equivalent to: > > (i==0 ? 1 : 0); > > > Regards, > > David Mathog > mathog@caltech.edu > Manager, Sequence Analysis Facility, Biology Division, Caltech > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bool wrapping] Request for warnings on implicit bool to int conversions 2012-03-29 10:29 ` David Brown @ 2012-03-29 17:49 ` mathog 0 siblings, 0 replies; 15+ messages in thread From: mathog @ 2012-03-29 17:49 UTC (permalink / raw) To: gcc On 29-Mar-2012 03:20, David Brown wrote: > On 29/03/2012 00:52, mathog wrote: >> A better solution for the aesthetics would have been (it is a bit >> late >> now) to implement the missing unary negation operator: >> >> !!b; //T->F, F->T >> > > You can't do that, because "!!" is already a useful operator on > integers - it turns anything non-zero into 1 while leaving 0 alone, > and is effectively an "int to bool" conversion operator. Right, hence the "a bit late now". (I'm going to use "unary operator" for the rest of this to mean operations like ++, an operator that changes the value of the operand all by itself. There is some other technical term to distinguish that from a unary "-", for instance, but I have long since forgotten what it is.) I understand we aren't likely to ever see !! as a unary operator because of backwards compatibility issues. Since unary not is an obvious thing to have added to C99 along with bool, my guess is that they couldn't figure a way to squeeze it in without stepping on !! or something else still needed for backwards compatibility. This highlights the problem with defining unary operators by repetition of single characters, rather than by using a special symbol to indicate all of the unary operators, something like i@+ , i@- instead of i++, i-- +@i , -@i instead if ++i, --i and so forth, which would have allowed for unary variants of more operators. Including those not considered at the time the language was first constructed. Here: !@b and b@!, but also for ~, for instance. We are all used to "++" now, but if you think about it "add twice" is not a natural synonym for "increment", whereas <var><unary operator symbol><plus> is. Anyway, this ship sailed a long, long, long time ago. Regards, David Mathog mathog@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Request for warnings on implicit bool to int conversions 2012-03-28 20:30 ` mathog 2012-03-28 22:21 ` Michael Witten @ 2012-03-28 22:28 ` Michael Witten 1 sibling, 0 replies; 15+ messages in thread From: Michael Witten @ 2012-03-28 22:28 UTC (permalink / raw) To: David Mathog; +Cc: gcc On Wed, Mar 28, 2012 at 20:30, David Mathog wrote: > ... > >> gcc -std=c99 -pedantic -Wall -O0 -fdump-tree-gimple d.c > > > That's a trick worth knowing. Thanks! > Ran that on a test program and in every case but one there was an implicit > > (int) b > > on sections of code which I though should generate warnings. (Math ops on > bools, comparison operations of > bool with ints.) The one exception in that little program was: > > b=2; > > which came out as > > b=1; > > In that case the compiler must have performed an implicit > > 1 = (bool) 2 > > Also these forms all generated implicit int conversions > > if(b==1) > if(b==2) > if(b==0) > > whereas > > if(b) > > did not. > > So let's turn this around. If the compiler warned on all implicit > conversions of bool <-> int, > what program lines would it warn on that it shouldn't? It would warn on: > > if(b==1) > if(b==0) > > but I would argue that line is inappropriate for a bool type, and should be > written as: > > if(b) > > With two bool variables, this also did not generate an implicit conversion > (and so would not warn, > which is appropriate): > > if(b1 || b2) > > Whereas this less preferred form would have generated an implicit (int) [and > a well deserved warning] > > if(b1 + b2) Your suggestion is probably a good idea, but as with all good ideas, it will probably not get implemented because most people don't care. Therefore, I'd suggest writing a patch and submitting it; people will no doubt be a lot more receptive when you convey your thoughts in hard-nosed, precise code, ESPECIALLY because that means the work has already been done! Sincerely, Michael Witten ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Request for warnings on implicit bool to int conversions 2012-03-27 22:43 Request for warnings on implicit bool to int conversions mathog 2012-03-28 1:00 ` Paolo Carlini @ 2012-03-28 9:00 ` Franz Sirl 1 sibling, 0 replies; 15+ messages in thread From: Franz Sirl @ 2012-03-28 9:00 UTC (permalink / raw) To: gcc Am 2012-03-28 00:43, schrieb mathog: > The C99 bool data type, and the similar type in C++, currently (v 4.5.2) > do not generate > warnings for any of these sorts of operations: > > bool b; > > b = 3; > b++; > b += 2; > if(b == 3) The last one is PR 44077. Franz ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2012-03-29 17:49 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-03-27 22:43 Request for warnings on implicit bool to int conversions mathog 2012-03-28 1:00 ` Paolo Carlini 2012-03-28 1:19 ` Gabriel Dos Reis 2012-03-28 2:21 ` Russ Allbery 2012-03-28 2:30 ` Gabriel Dos Reis 2012-03-28 2:40 ` Russ Allbery 2012-03-28 2:48 ` Russ Allbery 2012-03-28 19:32 ` [bool wrapping] " Michael Witten 2012-03-28 20:30 ` mathog 2012-03-28 22:21 ` Michael Witten 2012-03-28 22:52 ` mathog 2012-03-29 10:29 ` David Brown 2012-03-29 17:49 ` mathog 2012-03-28 22:28 ` Michael Witten 2012-03-28 9:00 ` Franz Sirl
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).