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

Groups > comp.lang.c > #400053

Re: Constants and undefined behavior

Show all headers | View raw

On 14/06/2026 16:33, Dan Cross wrote:
> In article <110k0mp$329k6$1@dont-email.me>,
> David Brown  <david.brown@hesbynett.no> wrote:
>> On 13/06/2026 14:02, Dan Cross wrote:
>>> In article <110ghmv$21vi3$1@dont-email.me>,
>>> David Brown  <david.brown@hesbynett.no> wrote:
>>>> [snip]
>>>> As for my '"modern compilers are evil" crowd' comment, there are people
>>>> (not anyone involved in this discussion) who really do fall into that
>>>> camp.  I've seen people who are experienced and respected developers
>>>> make all sorts of accusations to compiler developers, claiming they are
>>>> only interested in high scores on synthetic benchmarks and directly
>>>> insulting their motivations and integrity, blaming them for "breaking"
>>>> their code that relied on the effects of some kinds of UB.  It is always
>>>> frustrating when you have code that works fine with one compiler
>>>> version, but using another compiler results in failure due to UB in your
>>>> code - especially if writing correct code gives inefficient results with
>>>> the first compiler.  And it's fine to say you'd be happier if a
>>>> particular thing that is UB in C were not UB - but it is unreasonable to
>>>> blame compiler developers for implementing the language as it is defined.
>>>
>>> Eh...I think those people have a point.
>>>
>>> Note, I don't think that "modern compilers are evil" (I mean,
>>> wow, that's a strong word) and I certainly do not think it is
>>> appropriate to malign the people who write them personally over
>>> what one does with code.
>>
>> I think it is important for tools to be helpful, and it's fine to
>> complain if a tool is being directly unhelpful - or ask for improvements
>> when you think it could be better.
> 
> Yes.
> 
>>> But I _do_ think it is fair to say that UB is very easy to fall
>>> into in C, that programs that have worked correctly (insofar as
>>> their intended behavior as written) for years can suddenly fail
>>> because latent UB is treated differently in a point revision of
>>> a compiler, and that that (as you point out) can be incredibly
>>> frustrating for the authors.
>>
>> It can certainly happen, yes.  And I fully sympathise on these few
>> occasions when changes to the standard has meant that code that
>> previously had defined behaviour, now has different or undefined
>> behaviour.  (However, I think that for some kinds of code, programmers
>> could be better at specifying exactly what standards their code
>> requires, and the standards they use when compiling code.)
>>
>> But it is important to realise that if you write code with UB, it is
>> /your/ mistake - not the mistake of the compiler developers, or the
>> mistake of the standards authors.  Compiler vendors can (and do!) try to
>> help programmers find their mistakes - experience shows, however, that
>> many programmers reach first for bug report forms or complaints in
>> forums before compiler tools like sanitisers or even enabling warnings
>> on their builds.
>>
>> Programming in C is a cooperative effort - including the standards
>> authors, the compiler vendors, and the C programmers.  Each group can
>> try to help the others, but each is ultimately responsible for their own
>> part.
> 
> Here's the problem that I have with this line of reasoning.  C
> is a language that has considerable history; there was a large
> body of C code written before the first standard was ever
> created, in 1988; C was a teenager.  And it took many years for
> decent quality ANSI C compilers to be ubiquitous.  C could
> legally drink by then.
> 
> "Undefined Behavior", in C, in the manner usually discussed in
> this newsgroup, was introduced with the first standard.  That
> means that there is --- still --- a large body of software that
> has "UB" that was put there before UB existed as a thing
> programmers needed to worry about in C.
> 
> Even once it was a part of C, the concept was communicated
> poorly.
> 

It is certainly the case that C code has been written for a long time. 
And it is certainly the case that some C code was written long ago, and 
is still used on systems today.  But I think it is important to keep in 
mind that the solid majority of C code is relatively recent.  Very 
little pre-C90 code is ever compiled with modern tools.  Code that is 
old and still in use is important code, but modern code and modern tools 
should not be kept back because of it.

Maybe there is scope for compilers to have better options for handling 
old code, other than the usual "Use -O0 to avoid optimising on UB" 
solution.  You could come a long way with a "treat all variables as 
volatile" flag, for example.

> Some people seem to delight in this, believing precision in
> interpreting the standard in abstruse ways is an expression of
> deep technical expertise; but it really is not.
> 

Agreed.

> Yes, UB is created by programmers.  However, in large systems,
> it may be that it was created inadvertantly; someone makes a
> change that subtley invalidates some invariant that an unknown
> caller far away in the code base (or in another one that relies
> on the change via an indirect dependency) and now you've got UB;
> locally, everything appears correct; but it's the combination
> where the UB manifests.
> 

That can certainly happen.  But that's just bugs in the code.  I don't 
see why UB should be considered as something special here.  People 
making changes to existing code sometimes misunderstand things, or 
accidentally break something that worked before.  That's life as a 
programmer, and there are techniques to reduce the risk - code reviews, 
linters, testing regimes, etc.  Nothing gives 100% guarantees, and 
everything has to weigh risks, consequences, costs and resources.  UB is 
not special here.

>>> Regehr called out a dichotomy with UB: programmers using a
>>> language hate it; compiler writers love it.
>>
>> I think Regehr has made some good points in his writings, but I do not
>> agree with him on everything.
>>
>> As a programmer, I am a fan of the concept of UB.  I am quite happy with
>> the idea that operations have a pre-condition, and that if there is no
>> "right answer" for a given input, I should not provide that input.  I
>> prefer that signed integer arithmetic overflow is UB, and do not want it
>> to be wrapping or have some other semantics - to me, it is far clearer
>> that way.  If I have UB in my code, it's a bug - no different from any
>> other bug I might make.
> 
> This example makes little sense to me.  If you don't want
> integer overflow, then don't overflow; the techniques for
> avoiding it are pretty well known.  But why is specifically
> better that it is UB, rather than than trapping in debug
> builds, or having IB semantics based on the underlying machine?
> It seems to be that the burden on the programmer is the same.
> 

UB means precisely that I can choose trapping, or IB, or optimising on 
the assumption it does not happen.  If signed integer overflow were 
defined as wrapping, then compilers could not put in traps to catch the 
errors because as far as the language is concerned, they are not errors. 
  If they are defined as causing traps, then that's the semantics - 
compilers could not optimise code assuming overflow does not happen, 
unless it can prove there is no overflow.

And making it defined behaviour gives programmers the mistaken idea that 
they don't need to avoid overflow because there is no UB.

Making this UB is an admission of the blindingly obvious - there is no 
correct answer when signed integer overflow occurs.  It tells 
programmers that it is a mistake to let your arithmetic overflow, and it 
allows tools to help programmers avoid these mistakes, and it allows 
compilers to give programmers the most efficient results from known good 
code rather than adding unnecessary run-time checks that are never 
triggered.

>> It is the case that in C, there are some kinds of UB that can be quite
>> subtle.  However, you rarely need to risk meeting them.  Yes, there are
>> pitfalls - don't go near them, and they don't matter.
> 
> I disagree.  I think almost all non-trivial programs have UB to
> a greater or lesser extent, whether they intend to or not.
> 
>> However, it is unfortunately the case that sometimes avoiding UB can be
>> costly in performance terms.  An example would be if you have need of
>> type-punning - perhaps you have a float in memory and you want to access
>> it as an uint32_t for some reason.  Casting a float * to an uint32_t *
>> and using that new pointer is UB.  Some compilers will nonetheless
>> generate the code you want after such a cast.  Some compilers might not,
>> depending on details of the rest of the surrounding code, because it is
>> UB.  A non-UB solution would be to use memcpy(), or a type-punning
>> union.  For highly optimising compilers, that's fine - the code
>> generated by gcc or clang for a memcpy() here is likely to be as
>> efficient as you could get - directly reading the float from memory to
>> an integer register.  For other compilers, however, you might get a call
>> to a memcpy() library function in an external DLL, taking orders of
>> magnitude more cycles.  What is the poor programmer to do?  Write code
>> that is portable and correct, but very slow with some implementations?
>> Write code that "cheats" and is efficient on some implementations but
>> might not give the desired results on others?  Use pre-processor
>> monstrosities to detect different compilers and adapt accordingly?  That
>> is what I see as the biggest issue resulting from compiler optimisation
>> based on UB.  I don't know what the "best" answer here is.
> 
> This is kind of my point.  If you need a fast way to convery
> 

(I think you missed a bit of your answer here?)

>>> Here's my own vignette: I was chatting with a friend who works
>>> on LLVM and clang some time ago.  I said, "I don't want UB" and
>>> he replied, "no, you really do."  I asked him what he meant and
>>> he responded that I wanted a compiler that is capable of
>>> optimizing my program; "sure, but I still don't want UB."  We
>>> went on for a bit, and it became clear that he saw UB as _the_
>>> vehicle for unlocking optimization.
>>>
>>> I realized that we were not speaking the same language _at all_.
>>> He and I both wanted a language where we could write programs
>>> that yield efficient object code.  He saw UB as essential for
>>> that; but what I want is a language with well-defined semantics
>>> that can be aggressively optimized.
>>
>> I too want a language with well-defined semantics that can be
>> aggressively optimised.  But I do not see UB as a hinder to that.
> 
> UB is literally the opposite of well-defined.
> 

I want good definitions of things that should be defined.  Things that 
cannot have good definitions, are fine left undefined.  A language 
standard should not be trying to define the behaviour of /everything/.

>> I am happy knowing that I cannot divide by 0,
> 
> Yup.  That should be a trap.

For some programs, yes.  For others, no.

> 
>> or find the square root of a negative number (in the real
>> domain).
> 
> Yup.  That should be a trap.
> 

For some programs, yes.  For others, no.

>> I am happy knowing that I cannot add two ints if their sum
>> overflows the range of their type,
> 
> Yup.  That should be a trap (if you want wrapping semantics, you
> should request it explicitly).

I agree that wrapping semantics should be something you have to ask for. 
  (As an aside, I think it is a mistake for languages to have types that 
have wrapping semantics - it's the operations that should wrap, not the 
types.  Zig gets it right by distinguishing between "x + y" and "x +% y".)

I don't want to pay the price for checks, traps, and limited 
re-arrangements and optimisations when I know my expressions don't 
overflow.  But I am also happy to be able to get a trap when I ask for it.

> 
>> and that I cannot call a function with a different number or
>> type of parameters than its definition.
> 
> Yup.  That should be a compile-time error.
> 

There I agree entirely.  The build model of compiling units to separate 
object files without any information beyond symbol names made sense 50 
years ago - we should be doing far better now.  (We /can/ do far better, 
but it requires conventions in the way you write your C code and the 
options used when compiling or linting the program.)

>> I have a great deal of difficulty seeing how things could be
>> any different, other than in a managed language with significant
>> overhead from run-time checks - and that goes against the
>> "aggressively optimised" requirement.
> 
> There are existence proofs of other languages that can, and do,
> do these things, and do them well.  I hate to keep beating this
> drum, but I think Rust does well here: in safe Rust, UB is a
> compile-time error; in *unsafe* Rust, there are tools to help
> find where programmers violate the language's invariants.
> 

Certainly it is possible to eliminate a number of things that are UB in 
C.  UB that is not necessary, or not useful, is a bad thing in a language.

But I think it is equally bad to give things a definition simply to be 
able to say there is no UB.  It is, IMHO, entirely /wrong/ of a language 
to define integer overflow as wrapping simply so that it is not UB.  I 
do not see a guaranteed incorrect result that likely has catastrophic 
consequences in a program as being better than UB.  (I believe Rust 
defines integer overflow as trapping in "debug" mode and wrapping in 
"release" mode, which I think is a horrendous idea.)

>> Having "well-defined semantics" does not mean the language should accept
>> anything that happens to fit the syntax and grammar rules, or that all
>> functions and operations should give a defined result for all inputs.
> 
> I never said that it did.

I didn't say you said it did :-)

> 
>> It means that the set of valid inputs is clearly defined, along with the
>> outputs and effects you get when the inputs are valid.
> 
> So I was the one who said "well-defined semantics" and I had a
> specific meaning in mind.  Your definition is incomplete with
> respect to that meaning: in addition to what you said, invalid
> inputs should be rejected, either as a compile time error, or by
> generating an exception or panic at runtime.  If you want to
> live dangerously and turn the runtime checks off for performance
> reasons, then you get 2's complement behavior for integers or
> whatever the machine does for the others.
> 

I am all in favour of compile-time checks and rejecting code with errors 
(not just UB) as soon as possible.  The "perfect" language is one where 
you really can follow the old Ada saying - if you can make it compile, 
it's ready to ship.

I don't live dangerously by not having run-time checks on integer 
overflows.  I make sure my code does not have them, so checks are 
unnecessary.  For some of my code, if it "panicked" somewhere in 
calculations, that would be a disaster - when you have code controlling 
power electronics, a sudden stop can mean short-circuits and components 
releasing their magic grey smoke.

Thinking that run-time checks will save you from UB is wishful thinking. 
  How are you going to have run-time checks that a pointer parameter 
points to a valid object of the right type?  You can check for a 
null-pointer, but that's about it.  Some things that are potential UB in 
C are inherent in the type of language - checking for such problems (at 
compile-time or run-time) needs a language that has a different way of 
handling objects and pointers so that you cannot have arbitrary pointers 
to arbitrary objects.

C is not a language suitable for such run-time or compile-time checks - 
it is a language for getting the highest efficiency because the 
programmer takes responsibility for getting things right.  You are 
correct that large programs normally have bugs (of which UB is just one 
class) - the risk of bugs goes up with the size of the code base.  The 
corollary is that C is not a language suitable for large programs.

Rust, I think, reduces the risk of some kinds of bugs.  So does C++, 
when used carefully.  Most code, however, is best written in languages 
where these issues cannot occur - or at least where checks can be done 
without a measurable impact.  For example, if you use Python, you never 
have integer overflow, and you never have invalid pointers.


>> (There are plenty of points in the C standards where the wording could
>> make the semantics clearer, or where the range of input values could
>> easily have been larger - I am not suggesting C is as well-defined as it
>> could reasonably be.)
> 
> It's not just that it's nowhere close to being as well-defined
> as it should be, it's because the language as defined permits
> behavior that varies far too widely, specifically because of UB.
> 
> Consider one of the examples you gave: signed integer overflow.
> The standard doesn't say that you _can't_ add two numbers
> together if you overflow, it just says that if you do, the
> language imposes no requirements on the resulting behavior.  It
> may trap, it may elide the addition entirely, or it may do it
> and let the result be whatever the underlying machine does.
> 
> That is, the _language_ does not say that it's a bug; it says
> that it's not going to say anything about it at all.
> 

I'd be happy for the C standard to say that signed integer overflow is a 
bug, or that code is not allowed to overflow its integer arithmetic.  I 
would not be happy if it said compilers must trap on the bug or handle 
it in some specific way - what happens when a bug is reached is still 
UB.  And if the wording of the standard were changed to call it a "bug" 
rather than "UB", it would make absolutely zero difference to the way I 
write my code.

> This is one reason the committee is trying to reign some of this
> in.
> 
>>> That, I think, is the tension: there was a fundamental breakdown
>>> in communication between the users of the language, and those
>>> defining and implementing it.  My subjective sense is that in
>>> the past few years things are getting somewhat better, but it is
>>> hard to evolve something as critical and widely used as C.
>>
>> Communication between the separate parties is always an issue, and it is
>> easy for it to be a one-way street with a language standards committee
>> dictating the rules with little attention to feedback, then compiler
>> vendors following these rules without listening to the users.
>>
>> A challenge here, perhaps, is that users are a very diverse group.  How
>> much should compiler vendors cater for those that put a lot of effort
>> into correctness and want top efficiency, or those that are less
>> knowledgable about the language but want to avoid the consequences of
>> their mistakes?  What about those working with old code written for
>> different compilers with different unwritten rules?  It is not easy to
>> please everyone.
> 
> I think that's simplistic; not many programmers actively want to
> "avoid the consequences of their mistakes."  Do you really
> believe that they do?  If so, why?

It was badly worded - I meant that programmers do not want mistakes that 
they might make to lead to additional problems.  We can all appreciate 
and expect that if we make a mistake in code with an incorrect 
calculation, that will give incorrect output, or perhaps a crash in the 
program.  But we hope that it will not lead to corruption of a 
filesystem, or an exploitable security hole - something out of 
proportion with the mistake.

> 
> Conversely, there *is* this kind of machismo attitude among many
> C programmers that it requires a superior intellect to truly
> understand this language, and those who do not (or who make any
> mistake in their understanding) are simply unworthy.  I have
> repeatedly observed this over many decades now, and when I see
> it, I think that it is odious.

In my field, people usually put a lot of effort into writing code simply 
and clearly.  You avoid mistakes not by being "clever", but by being 
meticulous and careful.  I don't think successful C programming requires 
greater intellect, knowledge or experience compared to other programming 
languages - but it /does/ require an appropriate attitude.  You are 
working with sharp knives - pay attention to what you are doing, and 
you'll be fine.

> 
> My experience is that most programmers are highly intelligent,
> capable people.  They are not wrong to want behavior they can
> rely on, particularly when things are not obvious, as they
> often are not.  They also want a language that requires a less
> lawyerly read of to understand its semantics; that could go the
> way of formality (my preferred approach) or just clearer
> exposition.  Either would be preferable to the current state.
> 

I was avoiding signed integer overflow long before I had read any C 
standards or even knew about the term "UB".  Programming in C does not 
need a lawyer knowledge of the language.  It is just like programming in 
any other programming language - use features that you know are correct, 
and if you want to do something and don't know how to do so correctly, 
look it up.

> In fairness, I think the current members of the committee
> recognize this.
> 
>>>> I am not in any way saying that critics of aspects of C (the language,
>>>> the standards, or compiler implementations) should be dismissed or
>>>> despised - merely that the example of loop elimination leading to UB and
>>>> unexpected results is regularly used as "evidence" by those that hold
>>>> extreme positions about C, despite it being very unrealistic for the
>>>> issue to cause problems in real coding practice.
>>>
>>> The kernel I am working on has about 5 million lines of code.
>>> That code has been evolving for 40 years; some of it predates
>>> the ISO standards and even the ANSI standard.  It has been
>>> updated for newer compilers, sure, but in some places the
>>> treatment is surface-level: using ISO-style function prototypes
>>> and definition syntax, for example.  But deep problems remain in
>>> parts, and contraints on engineering resources couple with
>>> economic and business pressures so that it's not going to get
>>> cleaned up any time soon.  I'm sure there is UB in it; in fact,
>>> I know there is.  But them's the breaks; and yet, customers are
>>> using it in production.  Because of this, upgrading toolchains
>>> is laborious and complex, and takes a lot of time, and new
>>> compilers are (rightly) viewed with suspicion.  That is not a
>>> great situation, but I don't think anyone is angry at the
>>> compiler people over it.
>>
>> I think that is a good way to handle the situation.  In my projects, I
>> do not normally upgrade or change toolchains.  While I think the risk of
>> UB is small in my own code, small does not mean non-existent.  And for
>> my work, generated code that behaves correctly in terms of C semantics
>> but has different execution times or code size might also be an issue -
>> so changes in toolchains mean a lot of extra testing and qualification.
> 
> Obviously in a production setting tools should be tested and
> qualified.  But the danger posed by UB adds unacceptable risk on
> large projects, and the burden for updating a toolchain is too
> high.  That is as much an indictment of the language as of any
> particular project.
> 
> As a counter example, there was the Harvey project, which was a
> fork of Plan 9 where the Plan 9 C dialect was replaced with ISO
> C; we accounted for this by having CI build with 6 seperate
> compilers; this flushed out a lot of bugs.
> 
> I am surprised that more projects do not adopt canary CI builds
> against newer toolchains.
> 
>> In addition, for some microcontrollers the toolchains have relatively
>> small user bases and consequently higher risks of unknown bugs in the
>> toolchains themselves.  Sometimes there are also implementation-specific
>> features that change between versions (though that is less of an issue
>> these days).
> 
> Fun fact: part of the reason Google got involved in clang and
> LLVM development was because the vendor toolchain for a
> particular microcontroller used in android phones was buggy and
> would crash (that is, the compiler itself crashed).  The
> solution was not to live with it; it was to build a better
> toolchain.
> 

Buggy toolchains are always a pain.  (So is buggy hardware - 
microcontrollers and cpus have their errors too.)

> Google could afford to do that; I recognize not many
> organizations can.

Unfortunately that's true.

> 
>>> And just as it's not acceptable to blame compiler writers for
>>> implementating the language as it is defined, it's not really
>>> acceptable to blame programmers either; some of the people who
>>> put the UB there are (literally) dead, and there's just not
>>> enough time in the day to go clean it all up.  I wish there was
>>> more compassion for that.
>>
>> Being dead does not resolve you of the responsibility - the person that
>> wrote the code with UB is the person who wrote the code with the UB,
>> just like any other bugs.  That person wrote the code with the error.
> 
> See above.  Those people may well have written the code before C
> was standardized and before UB as we know it now existed.  Also,
> by definition UB is not an error.
> 
>> It might not be fair to hold it against them - there are a great many
>> possible reasons why it was not their fault (typically management is
>> more at fault than the coders!).  And placing blame is rarely a useful
>> exercise - usually it does not matter where the bugs came from, only
>> that they are there and need to be fixed or worked around.
> 
> Exactly.  The footguns hiding in C code that has worked
> perfectly for decades, dating back to before the standards
> existed, are legion.  Caveat emptor.
> 
> _Or_ the code may have been written with careful regard for the
> standard, but something _else_ may have been changed that now
> leads to exposure to UB.  For example, perhaps code was written
> that multiples two numbers, `a*b`; a known to be `unsigned int`
> when written, but `b` is a signed int.  But maybe that is hidden
> behind a typedef; some time in the future, the typedef is
> changed so that `a` is now `unsigned short`; perhaps someone
> realized that the domain values never exceed 16 bits and by
> changing the definition some critical structure now fits in a
> single cache line.  But also now the type promotion rules kick
> so that `a*b` happens with the factors as `signed int` and in
> there exist values of `a` and `b` where `a*b` overflows: UB.
> 
> The code had no UB; the change was elsewhere; no one saw this
> because the tests all passed and everything looked ok; then
> someone upgrades the compiler and now things break.
> 
> Who's fault is that?

There's no simple answer here.

But one thing is clear to me - "UB" is irrelevant here (and in many of 
your points).  It would not matter if everything had fully defined 
behaviour.  The point is that something is changed in one part of the 
code that has unexpected consequences in another part of the code.  Who 
cares if there is UB or not?  The issue is that the code does not work 
as intended or expected.  UB can provide situations where you have 
unexpected bugs - but so can all sorts of other things.

> 
> And no, this is not contrived; this is exactly the sort of thing
> that happens on large, long-lived projects.
> 
>>> As said earlier, C is what it is.  I suspect that it will
>>> continue to make incremental improvements, but we're basically
>>> stuck with what we have.
>>
>> Agreed.
> 
> ...but be careful blaming the programmer.
> 
Or the language, or the tools.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 19:53 +0200
  Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 20:15 +0200
    Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-27 18:49 -0500
      Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 04:53 +0000
        Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 02:35 -0500
          Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:32 +0000
            Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 20:07 -0500
        Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-28 11:48 +0200
      Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-28 09:18 +0200
        Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 04:57 -0500
          Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:35 +0000
          Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:52 +0200
            Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 05:20 -0500
              Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-29 13:22 +0200
                Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 15:16 -0500
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 13:52 +0200
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-30 14:40 +0200
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 16:36 +0200
                Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 15:48 -0500
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:14 +0200
                Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-31 13:25 -0500
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:14 +0200
              Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 15:22 +0200
              Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 03:49 +0000
        Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-28 12:47 -0700
          Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:56 +0200
            Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-29 11:00 -0700
      Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-28 17:12 +0200
        Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 14:07 -0500
          Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:54 +0000
            Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 10:02 +0200
              Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 12:19 +0100
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 14:46 +0200
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 14:22 +0100
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 17:15 +0200
                Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-05-29 15:59 +0000
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:12 +0100
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:48 +0200
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:09 +0100
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:00 +0200
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:14 +0100
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:09 -0700
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:05 +0100
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:34 +0200
                Re: this girl calls c ugly tTh <tth@none.invalid> - 2026-05-29 19:29 +0200
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 18:53 +0100
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:28 -0700
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 20:49 +0100
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:03 +0200
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 13:56 -0700
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:54 +0100
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 15:52 -0700
                Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 20:31 -0400
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 02:03 +0100
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 19:02 -0700
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:12 +0100
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-30 12:29 +0000
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 13:56 +0100
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 16:43 -0700
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-31 03:37 +0200
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 19:53 -0700
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:16 +0200
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:47 +0200
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:55 +0200
                Re: this girl calls c ugly Richard Harnden <richard.nospam@gmail.invalid> - 2026-05-31 09:12 +0100
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:49 +0200
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 11:10 +0100
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:18 +0200
                Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:24 -0400
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 17:35 +0200
                Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 12:46 -0400
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:24 +0200
                Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 18:26 -0400
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:28 +0200
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 15:54 -0700
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:39 +0200
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:33 -0700
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:48 +0200
                Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-02 06:37 -0400
                Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 05:06 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:28 +0000
                Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 03:37 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 16:31 +0000
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 13:36 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 23:49 +0000
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 18:04 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:10 +0000
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 23:50 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 02:20 +0000
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 12:39 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 23:15 +0000
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 18:51 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 09:46 +0000
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:07 -0700
                Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-09 01:25 +0000
                Re: Constants and undefined behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-09 18:29 -0400
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 16:01 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 12:36 +0000
                Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 16:49 +0200
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 15:20 +0000
                Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 18:08 +0200
                Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-11 16:30 +0000
                Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:52 +0200
                Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-12 02:20 +0000
                Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-13 14:57 +0200
                Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 15:26 -0700
                Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-22 03:40 +0000
                Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 07:50 -0700
                Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 14:26 -0700
                Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-22 03:56 +0000
                Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-29 06:27 -0700
                Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 15:47 -0700
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-06 16:36 -0700
                Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 16:43 -0700
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-06 17:41 -0700
                Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-05 10:41 +0200
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 10:49 -0700
                Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 16:15 -0700
                Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 18:06 -0700
                Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-07 22:34 -0700
                Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 23:05 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 10:19 +0000
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:12 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 14:37 +0000
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 18:30 +0000
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:55 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 23:32 +0000
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:47 -0700
                Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-11 08:56 +0200
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 11:38 +0000
                Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-11 14:05 +0200
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 15:38 -0700
                Re: Constants and undefined behavior scott@slp53.sl.home (Scott Lurndal) - 2026-06-11 23:07 +0000
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 17:43 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 02:02 +0000
                Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 17:34 +0200
                Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 10:58 +0200
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-12 12:27 -0700
                Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-13 12:36 +0200
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:03 +0000
                Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 12:35 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:02 +0000
                Re: Constants and undefined behavior ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-13 12:13 +0000
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:44 +0000
                Re: Constants and undefined behavior ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-14 17:22 +0000
                Re: Constants and undefined behavior scott@slp53.sl.home (Scott Lurndal) - 2026-06-14 21:24 +0000
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-15 17:52 +0000
                Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-13 18:32 +0200
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-14 14:33 +0000
                Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-14 22:02 +0200
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-14 15:55 -0700
                Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-15 10:09 +0200
                Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-15 10:43 +0000
                Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-15 16:01 +0200
                Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-15 17:57 +0000
                Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-16 10:10 +0200
                Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-24 17:45 +0200
                Re: Constants and undefined behavior "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-24 12:27 -0700
                Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-24 16:58 +0200
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-15 19:26 +0000
                Re: Constants and undefined behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-15 21:59 -0400
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-16 04:59 +0000
                Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-29 05:41 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-29 15:23 +0000
                Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 07:36 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:27 +0000
                Re: Constants and undefined behavior Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-20 04:12 +0800
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 13:29 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 02:08 +0000
                Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 11:02 +0200
                Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 17:45 +0200
                Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-10 15:11 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 22:44 +0000
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 16:19 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 11:50 +0000
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 16:28 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 23:46 +0000
                Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 18:29 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 01:54 +0000
                Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 11:37 +0200
                Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 07:58 -0700
                Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:28 +0000
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:35 -0700
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 06:29 -0700
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 16:10 +0200
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:29 -0700
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 06:41 -0700
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:24 -0700
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 08:35 -0700
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 17:33 +0000
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-09 00:54 -0700
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 10:08 +0000
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 13:40 -0700
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 09:37 -0700
                Meaning of "expression" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 14:05 -0700
                Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 15:17 +0200
                Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-09 14:53 +0100
                Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 16:30 +0200
                Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-09 17:13 +0200
                Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:34 -0700
                Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 09:04 +0200
                Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-10 11:10 +0100
                Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 13:29 +0200
                Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 03:17 -0700
                Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 13:43 +0200
                Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:08 -0700
                Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-11 09:10 +0200
                Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:29 +0200
                Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-12 12:55 +0200
                Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-13 15:01 +0200
                Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:12 +0200
                Re: Expression statements (was Re: Meaning of "expression") James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-11 15:13 -0400
                Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 00:37 +0200
                Re: Expression statements (was Re: Meaning of "expression") scott@slp53.sl.home (Scott Lurndal) - 2026-06-11 23:05 +0000
                Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 01:18 +0200
                Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 17:41 -0700
                Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-28 02:49 +0200
                Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-27 21:00 -0700
                Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-28 09:52 -0700
                Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 18:28 -0700
                Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 13:40 -0700
                Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-14 14:13 -0700
                Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-19 08:32 -0700
                Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-19 15:09 -0700
                Re: Expression statements (was Re: Meaning of "expression") James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-11 20:41 -0400
                Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-28 03:16 +0200
                Re: Expression statements (was Re: Meaning of "expression") tTh <tth@none.invalid> - 2026-06-09 19:27 +0200
                Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-09 19:19 +0100
                Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:22 -0700
                Re: Meaning of "expression" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 00:42 -0700
                The meaning of 42 ; (was: Re: Meaning of "expression") Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 19:42 +0800
                Re: Meaning of "expression" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-15 05:36 -0700
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:22 +0000
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 23:56 -0700
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-07 13:37 +0000
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-07 15:09 -0700
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 02:33 +0000
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 09:37 -0700
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-15 17:29 -0700
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:30 +0000
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 00:16 -0700
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 12:41 +0000
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 17:37 +0000
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 16:05 +0200
                Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 13:59 -0700
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 13:05 +0000
                Parentheses (was: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 14:38 +0100
                Re: Parentheses (was: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
                Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-03 22:30 +0000
                Re: Parentheses Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-03 16:24 -0700
                Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-04 02:03 +0000
                Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 01:12 +0100
                Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-04 01:58 +0000
                Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 11:37 +0100
                Re: Parentheses cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 10:51 +0000
                Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 12:47 +0100
                Re: Parentheses Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 14:57 +0200
                Re: Parentheses cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 14:31 +0000
                [OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 15:54 +0200
                Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 15:19 +0100
                Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
                Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 17:39 +0200
                Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:36 +0000
                Re: [OT] Fancy graphics (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 21:33 +0000
                Re: [OT] Fancy graphics (was Re: this girl calls c ugly) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 14:43 -0700
                Re: [OT] Fancy graphics (was Re: this girl calls c ugly) ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-02 17:08 +0000
                Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 19:19 +0000
                Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-04 00:11 +0000
                Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:39 -0700
                Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-03 13:14 +0000
                Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:10 +0000
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:31 +0000
                Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:15 -0400
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 16:29 +0200
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 03:45 -0700
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 04:02 -0700
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 09:04 -0700
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 18:11 +0100
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:34 +0000
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 19:10 -0700
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:12 +0100
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:36 +0200
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:26 -0700
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 02:34 -0700
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 12:40 +0100
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 14:35 +0200
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 14:18 +0100
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:47 +0200
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:57 +0200
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 16:27 +0200
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 16:46 +0100
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 20:15 +0200
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 20:54 +0200
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 20:29 +0100
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 14:06 -0700
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 22:47 +0100
                Famous (hopefully last) words [on this topic] Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-05 00:27 +0200
                Re: Famous (hopefully last) words [on this topic] Bad Post <invalid@invalid.invalid> - 2026-06-05 01:20 +0100
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 16:09 -0700
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 00:44 +0100
                Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-04 17:26 -0700
                Re: this girl calls c ugly antispam@fricas.org (Waldek Hebisch) - 2026-06-05 12:58 +0000
                Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-05 14:27 -0700
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:47 +0000
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 00:53 -0700
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 11:04 +0100
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 05:34 -0700
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:45 +0000
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:44 +0000
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-06 07:39 +0200
                Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-04 15:25 -0700
                Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-12 08:31 +0000
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 09:29 +0200
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 12:39 +0100
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 15:42 +0200
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 16:50 +0100
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:09 -0700
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 20:29 +0100
                Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 16:18 +0000
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 17:23 +0100
                Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 16:47 +0000
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 19:57 +0100
                Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:34 +0000
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 22:28 +0100
                Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 21:58 +0000
                Re: this girl calls c ugly Richard Harnden <richard.nospam@gmail.invalid> - 2026-06-04 23:25 +0100
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:49 +0000
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 19:47 +0200
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 21:04 +0200
                Re: this girl calls c ugly Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-06-04 19:13 +0000
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 10:34 +0200
                Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-12 08:32 +0000
                Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-12 11:05 -0700
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 12:11 -0700
                Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-04 16:33 -0400
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 14:16 -0700
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 00:02 +0000
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 18:36 -0700
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:54 +0000
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 05:49 -0700
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:01 -0700
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 11:53 -0700
                Re: this girl calls c ugly Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-06-04 18:45 +0000
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 20:19 +0000
                Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:31 +0000
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 20:41 +0000
                Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:49 +0000
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 00:03 +0000
                Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-05 00:18 +0000
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 03:02 +0000
                Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-05 14:04 +0000
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:49 +0000
                Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-06 15:13 +0000
                Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-06 17:53 +0000
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 11:59 -0700
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:21 +0200
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 06:38 -0700
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 09:52 +0200
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:42 -0700
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:50 +0200
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:47 +0100
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:55 +0200
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:39 -0700
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 15:11 -0700
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 08:41 +0200
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 02:07 -0700
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:38 +0200
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:01 -0700
                It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:39 +0000
                Re: It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:42 +0000
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 11:46 +0200
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 11:09 +0100
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:25 -0700
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 14:20 +0100
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:12 -0700
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 04:16 -0700
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-01 15:23 -0700
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 16:06 -0700
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 23:24 +0100
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:35 +0200
                Operator precedence in other (non-C, but "C-like") languages (Was: something about a girl) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:36 +0000
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 11:04 +0000
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 14:04 +0200
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 18:48 +0000
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 21:04 +0100
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:17 +0200
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:09 +0200
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 12:07 +0000
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 14:37 +0200
                Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:06 +0000
                Re: Microcontroller software stacks (was Re: this girl calls c ugly) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 14:13 -0700
                Re: Microcontroller software stacks (was Re: this girl calls c ugly) David Brown <david.brown@hesbynett.no> - 2026-06-22 08:58 +0200
                Re: Microcontroller software stacks (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-22 03:35 -0700
                Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-22 10:50 +0000
                Re: Microcontroller software stacks (was Re: this girl calls c ugly) David Brown <david.brown@hesbynett.no> - 2026-06-22 12:59 +0200
                Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-28 09:42 -0700
                Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 18:06 -0700
                Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 20:20 -0700
                Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 14:56 -0700
                Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-14 22:30 +0000
                Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 16:10 -0700
                Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-16 15:20 +0000
                Re: Storage needed when there are bit-field members antispam@fricas.org (Waldek Hebisch) - 2026-08-19 19:34 +0000
                Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-19 15:26 -0700
                Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-20 11:00 +0200
                Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-20 03:30 -0700
                Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-20 13:58 +0200
                Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-20 13:37 -0700
                Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-20 14:50 +0000
                Re: Storage needed when there are bit-field members "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-20 12:31 -0700
                Re: Storage needed when there are bit-field members antispam@fricas.org (Waldek Hebisch) - 2026-08-20 19:55 +0000
                Re: Storage needed when there are bit-field members Michael S <already5chosen@yahoo.com> - 2026-08-20 22:15 +0300
                Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 14:19 -0700
                Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-22 10:45 +0000
                Re: Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 15:23 +0000
                Re: Microcontroller software stacks (was Re: this girl calls c ugly) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 13:23 -0700
                Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:32 +0000
                Re: Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 15:04 +0000
                Re: Microcontroller software stacks (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-22 13:02 -0700
                Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 12:51 -0700
                Re: Microcontroller software stacks Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 05:02 +0800
                Re: Microcontroller software stacks bart <bc@freeuk.com> - 2026-08-15 01:18 +0100
                Re: Microcontroller software stacks Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-16 13:52 +0800
                Re: Microcontroller software stacks Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-14 14:06 -0700
                Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-14 21:42 +0000
                Re: Microcontroller software stacks Michael S <already5chosen@yahoo.com> - 2026-08-15 22:13 +0300
                Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-15 19:39 +0000
                Re: Microcontroller software stacks Michael S <already5chosen@yahoo.com> - 2026-08-15 23:22 +0300
                Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-16 14:38 +0000
                Re: Microcontroller software stacks Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-16 16:11 -0700
                Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 16:16 -0700
                Re: Microcontroller software stacks cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:34 +0000
                Re: Microcontroller software stacks antispam@fricas.org (Waldek Hebisch) - 2026-08-19 19:57 +0000
                Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 17:31 -0700
                Re: Microcontroller software stacks (was Re: this girl calls c ugly) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-20 04:51 +0800
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 03:58 -0700
                Re: this girl calls c ugly dave_thompson_2@comcast.net - 2026-06-06 19:02 -0400
                Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:11 +0000
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 16:08 -0700
                Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 16:32 -0700
                Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 17:12 -0700
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 14:07 +0200
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:10 +0200
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:18 +0100
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:17 +0200
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 21:47 +0100
                Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 15:57 -0400
                Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:34 +0200
                Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-29 23:18 +0000
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 01:26 +0100
                Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 04:25 +0000
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:01 +0100
                Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-31 00:29 +0000
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 10:59 +0100
                Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-01 00:33 +0000
                Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 02:26 +0100
                Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:24 +0200
          Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-29 08:09 +0200
            Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 04:15 -0500
              Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-29 14:58 +0200
                Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 01:04 -0500
            Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-29 23:20 +0000
              Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-30 11:18 +0200

csiph-web