Re: "undefined behavior"?

On 6/12/2024 6:30 PM, Keith Thompson wrote:

DFS <nospam@dfs.com> writes:

On 6/12/2024 5:30 PM, Barry Schwarz wrote:

On Wed, 12 Jun 2024 16:47:23 -0400, DFS <nospam@dfs.com> wrote:
>

Wrote a C program to mimic the stats shown on:
>
https://www.calculatorsoup.com/calculators/statistics/descriptivestatistics.php
>
My code compiles and works fine - every stat matches - except for one
anomaly: when using a dataset of consecutive numbers 1 to N, all values

40 are flagged as outliers.  Up to 40, no problem.  Random numbers

dataset of any size: no problem.
>
And values 41+ definitely don't meet the conditions for outliers (using
the IQR * 1.5 rule).
>
Very strange.
>
Edit: I just noticed I didn't initialize a char:
before: char outliers[100];
after : char outliers[100] = "";
>
And the problem went away.  Reset it to before and problem came back.
>
Makes no sense.  What could cause the program to go FUBAR at data point
41+ only when the dataset is consecutive numbers?

 

Also, why doesn't gcc just do you a solid and initialize to "" for you?

Makes perfect sense.  The first rule of undefined behavior is
"Whatever happens is exactly correct."  You are not entitled to any
expectations and none of the behavior (or perhaps all of the behavior)
can be called unexpected.

>
I HATE bogus answers like this.
>
Aren't you embarrassed to say things like that?

 He has nothing to be embarrassed about.  What he wrote is correct.

No it's not.
"Whatever happens is exactly correct." is nonsense.
"You are not entitled to any expectations" is nonsense.

The C standard's definition of "undefined behavior" is "behavior, upon
use of a nonportable or erroneous program construct or of erroneous
data, for which this International Standard imposes no requirements".
 If you don't like the way C deals with undefined behavior, that's
perfectly valid, and a lot of people are likely to agree with you.

Thanks for feeling my pain!
It's frustrating.  By now I spent a half-hour dealing with it.  gcc could've just filled the char[] variable with 0s by default.  I bet that would save a LOT of people time and headaches.

But I advise against lashing out at people who are correctly explaining
what the C standard says.

The C standard really says "Whatever happens is exactly correct."?

DFS, since you've been posting in comp.lang.c for at least ten years,

Time flies.
How do you know I've posted here that long?

I'm surprised you're having difficulties with this.

I'm surprised at some of the wonkiness of gcc and C.
* warns relentlessly when the printf specifier doesn't match the var
   type, but gives no warning when you use an int with memset (instead of
   the size_t specified in the function prototype).
* a missing bracket } throws 50 nonsensical compiler errors.
* warns of unused vars but not uninitialized ones
* one uninitialized var makes your program do crazy things.  Worse than
   crazy is it's identically crazy each time.
./prog 40 -c
outliers: none
./prog 41 -c
outliers: 41
./prog 42 -c
outliers: 41 42
./prog 43 -c
outliers: 41 42 43
./prog 44 -c
outliers: 41 42 43 44
etc.  And none were outliers - not even close.
At least if it showed nonsense data it would be easier to track down. Maybe.
The thing is, none of those values (40+) were ever in that char[] prior to running the code for a set of 50 consecutive values.
And I edited/compiled the code many times, but still got the identical error.
I doubt my environment (gcc 11.4 on Windows Subsys for Linux on Ubuntu) has anything to do with it.