Many thanks to lcc-win...

[Chris M. Thomasson]

This compiler just helped me find a bug that compiled right along wrt
GCC 5.1.0 on windows even using: -Wall -pedantic -Wextra -Wall

Take a look at the following c99 crude code and try to find the bug:
____________________
#include <stdio.h>
#include <assert.h>
#include <complex.h>
#include <tgmath.h>


void
ct_iterate_pixel(
double complex z,
double complex c,
unsigned int imax
){
//printf("z = %.1f%+.1fi\n", creal(z), cimag(z));

for (unsigned int i = 0; i < imax; ++i)
{
z = z * z + c;

if (abs(z) > 2)
{
putchar('-');
return;
}
}

putchar('*');
}


void
ct_iterate_plane(
unsigned int width,
unsigned int height,
unsigned int imax
){
assert(width > 1 && height > 1);

double xstep = 4.0 / (width - 1.0);
double ystep = 4.0 / (height - 1.0);

for (unsigned int y = 0; y < height; ++y)
{
for (unsigned int x = 0; x < width; ++x)
{
double complex z = (-2.0 + x * xstep) + I * (2.0 - y * ystep);
//printf("(%u, %u):z = %.1f%+.1fi\n", x, y, creal(z),
cimag(z));

ct_iterate_pixel(z, z, imax);
}

putchar('\n');
}
}


int main(void)
{
ct_iterate_plane(73, 73, 53);

fflush(stdout);
printf("\n\nFin, hit <ENTER> to exit...\n");
getchar();

return 0;
}
____________________


The problem is my call to abs! I need to be using cabs and lcc-win64
found it for me.

Thank you Jacob Navia!

:^)

[Chris M. Thomasson]

On 5/1/2017 10:27 PM, Chris M. Thomasson wrote:
> This compiler just helped me find a bug that compiled right along wrt
> GCC 5.1.0 on windows even using: -Wall -pedantic -Wextra -Wall
>
> Take a look at the following c99 crude code and try to find the bug:
> ____________________

[...]

> ____________________
>
>
> The problem is my call to abs! I need to be using cabs and lcc-win64
> found it for me.

My rational is from:

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/complex.h.html

the cabs is the right function to use damn it!

[David Brown]

(Or fabs, since you have tgmath.h #include'd)

I don't see the problem. The "abs" function is a normal int-to-int
function. If you have not declared it (and you have not #included
<stdlib.h> here), you should get a warning (which is included in gcc
-Wall) about an implicit function declaration. And if you /have/
declared it, then it is legal to use here (though logically incorrect).

My testing of gcc throws "warning: implicit declaration of function
‘abs’" even without any warning flags at all.


It is great that lcc-win has useful warning messages. And if it somehow
figured out that you didn't mean "abs" but really meant cabs, then that
is even better - but I can't see how it could do that without a high
risk of false positives. After all, abs() is not an unreasonable
function to apply to a complex double in this context.

[Mark Storkamp]

In article <oe955h$ii9$1...@dont-email.me>,

"Chris M. Thomasson" <inv...@invalid.invalid> wrote:

> This compiler just helped me find a bug that compiled right along wrt
> GCC 5.1.0 on windows even using: -Wall -pedantic -Wextra -Wall
>
> Take a look at the following c99 crude code and try to find the bug:

> The problem is my call to abs! I need to be using cabs and lcc-win64
> found it for me.
>
> Thank you Jacob Navia!
>
> :^)

What error message did lcc-win give? GCC gave me "warning: implicit
declaration of function 'abs'"

[Ben Bacarisse]

"Chris M. Thomasson" <inv...@invalid.invalid> writes:

> This compiler just helped me find a bug that compiled right along wrt
> GCC 5.1.0 on windows even using: -Wall -pedantic -Wextra -Wall

My gcc (slightly newer) tells me that abs is not declared even with no
-W arguments. Don't you get that?

> Take a look at the following c99 crude code and try to find the bug:

Did you tell gcc this is c99 code? I ask because I am wondering why I
get the warning and you don't.

> ____________________
> #include <stdio.h>
> #include <assert.h>
> #include <complex.h>
> #include <tgmath.h>
>
>
> void
> ct_iterate_pixel(
> double complex z,
> double complex c,
> unsigned int imax
> ){
> //printf("z = %.1f%+.1fi\n", creal(z), cimag(z));
>
> for (unsigned int i = 0; i < imax; ++i)
> {
> z = z * z + c;
>
> if (abs(z) > 2)
> {
> putchar('-');
> return;
> }
> }
>
> putchar('*');
> }

<snip remaining code>

> The problem is my call to abs! I need to be using cabs and lcc-win64
> found it for me.

Since the program includes tgmath.h so presumably it is supposed to use
the type-generic version which is fabs, not cabs. If you use cabs,
there's no reason to include tgmath.h.

<snip>
--
Ben.

[Chris M. Thomasson]

lcc-win gives the same: missing prototype for abs

For some reason, my GCC on windows:

gcc version 5.1.0 (tdm64-1)

does not give any warning whatsoever. Humm, should I try to report this
anomaly?

[Chris M. Thomasson]

On 5/2/2017 12:44 AM, David Brown wrote:
> On 02/05/17 07:33, Chris M. Thomasson wrote:
>> On 5/1/2017 10:27 PM, Chris M. Thomasson wrote:
>>> This compiler just helped me find a bug that compiled right along wrt
>>> GCC 5.1.0 on windows even using: -Wall -pedantic -Wextra -Wall
>>>
>>> Take a look at the following c99 crude code and try to find the bug:
>>> ____________________
>> [...]
>>> ____________________
>>>
>>>
>>> The problem is my call to abs! I need to be using cabs and lcc-win64
>>> found it for me.
>>
>> My rational is from:
>>
>> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/complex.h.html
>>
>> the cabs is the right function to use damn it!
>
> (Or fabs, since you have tgmath.h #include'd)
>
> I don't see the problem. The "abs" function is a normal int-to-int
> function. If you have not declared it (and you have not #included
> <stdlib.h> here), you should get a warning (which is included in gcc
> -Wall) about an implicit function declaration. And if you /have/
> declared it, then it is legal to use here (though logically incorrect).

Right

> My testing of gcc throws "warning: implicit declaration of function
> ‘abs’" even without any warning flags at all.

However, I get no warnings on my GCC: version 5.1.0 (tdm64-1)

> It is great that lcc-win has useful warning messages. And if it somehow
> figured out that you didn't mean "abs" but really meant cabs, then that
> is even better - but I can't see how it could do that without a high
> risk of false positives. After all, abs() is not an unreasonable
> function to apply to a complex double in this context.

[...]

I really did mean cabs, and since my gcc gave no warnings, I totally
missed this mistake until lcc-win got a hold of it. I need the absolute
value of the complex value. The radius, or modulus of the iterates of z
if you will.

[Chris M. Thomasson]

On 5/2/2017 11:25 AM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <inv...@invalid.invalid> writes:
>
>> This compiler just helped me find a bug that compiled right along wrt
>> GCC 5.1.0 on windows even using: -Wall -pedantic -Wextra -Wall
>
> My gcc (slightly newer) tells me that abs is not declared even with no
> -W arguments. Don't you get that?
>
>> Take a look at the following c99 crude code and try to find the bug:
>
> Did you tell gcc this is c99 code? I ask because I am wondering why I
> get the warning and you don't.

The full command line that CodeBlocks IDE passes to the GCC compiler is:

x86_64-w64-mingw32-gcc.exe -Wall -pedantic -Wextra -Wall -std=c99 -g -c
C:\Users\Chris\Documents\MingW\ct_c_test\main.c -o obj\Debug\main.o

It gives no warnings when abs is used. I notice that -Wall is used
twice, it must be an artifact of the IDE.

The version of gcc I am using is: gcc version 5.1.0 (tdm64-1) from:

http://tdm-gcc.tdragon.net


[...]

>> The problem is my call to abs! I need to be using cabs and lcc-win64
>> found it for me.
>
> Since the program includes tgmath.h so presumably it is supposed to use
> the type-generic version which is fabs, not cabs. If you use cabs,
> there's no reason to include tgmath.h.

I accidentally and prematurely included tgmath.h, sorry about that
non-sense. This code is a precursor for a simple, single file portable
fractal renderer in pure c99. It creates Plain PPM's. This is meant to
be used to aid peoples efforts wrt trying to solve a puzzle over in
sci.crypt:

https://groups.google.com/d/topic/sci.crypt/xytM7aFRfjQ/discussion

This should be completed today.

[Chris M. Thomasson]

On 5/1/2017 10:27 PM, Chris M. Thomasson wrote:

> This compiler just helped me find a bug that compiled right along wrt
> GCC 5.1.0 on windows even using: -Wall -pedantic -Wextra -Wall

[...]

Fwiw, here is my first step at the following code comprised of a single
file Plain PPM generating fractal renderer. Can anybody find any crap in
here, fwiw compiles clean on both lcc-win and my gcc:

** Be warned **, the code creates an output file called
ct_ffe_cipher.ppm. Can you run and open the file in a graphics editor?
It works for me with the Gimp. This non-sense with the hardcoded file
name will change to gain data in the arguments from the command line in
my next iteration of the code. Sorry about the crude state. ;^o

Anyway, the image is rendered with so-called "pretty" colors, the cipher
version, not shown here, makes garbage static. That version will be
completed fairly soon. Anyway, here is the naive first try c99 code, try
to open the resulting file: ct_ffe_cipher.ppm it creates, assuming that
somebody besides me can compile and run it:
_______________________
/* Chris M. Thomasson FFE Cipher Renderer ver:0.0.0.0 (pre-alpha)
5/2/2017 - Raw Experimental
_________________________________________________*/

#include <stdio.h>
#include <assert.h>
#include <complex.h>
#include <tgmath.h>


void
ct_iterate_pixel(

FILE* fout,

double complex z,
double complex c,
unsigned int imax
){
//printf("z = %.1f%+.1fi\n", creal(z), cimag(z));

double o = 999999999999.0;

for (unsigned int i = 0; i < imax; ++i)
{
z = z * z + c;

double dis = cabs(z);

o = (o < dis) ? o : dis;

if (cabs(z) > 256.0)
{
double sum = (i + 1) * (i + .01) * 123U;
unsigned int red = sum;
fprintf(fout, "%u %u %u ", red % 256U, 0, 0);
return;
}
}

//double sum = fabs(creal(z)) + fabs(cimag(z) + o) * 1223456U;
double sum = (o + .01) * 256;
unsigned int red = ((unsigned int)sum) % 256U;

fprintf(fout, "%u %u %u ", 0, red % 256U, 0);

return;
}


void
ct_iterate_plane(
FILE* fout,

unsigned int width,
unsigned int height,
unsigned int imax
){
assert(width > 1 && height > 1);

char const ppm_head[] =
"P3\n"
"# Chris M. Thomasson FFE Cipher Renderer ver:0.0.0.0 (pre-alpha)";

printf("fout:%p\n", (void*)fout);

fprintf(fout, "%s\n%u %u\n%u\n", ppm_head, width, height, 255);

double xstep = 4.0 / (width - 1.0);
double ystep = 4.0 / (height - 1.0);

for (unsigned int y = 0; y < height; ++y)
{
for (unsigned int x = 0; x < width; ++x)
{
double complex z = (-2.0 + x * xstep) + I * (2.0 - y * ystep);

//printf("(%u, %u):z = %.1f%+.1fi\n", x, y, creal(z),
cimag(z));

ct_iterate_pixel(fout, z, z, imax);
}

printf("processing y:%u of %u\r", y + 1, height);
}

printf("\nrender complete!\n");
}


int main(void)
{
FILE* fout = fopen("ct_ffe_cipher.ppm", "w");
assert(fout != NULL);

ct_iterate_plane(fout, 1024, 1024, 128);

fclose(fout);

fflush(stdout);
printf("\n\nFin, hit <ENTER> to exit...\n");
getchar();

return 0;
}

_______________________


Does this work for anybody else at all?

[David Brown]

You might want to report it to the TDM folk or ask in their forums or
mailing lists. I am guessing that the problem lies with the headers -
that one of the headers you have included declares abs(), or #include's
<stdlib.h>. Usually it is not a problem to have a standard header
included or a standard function declared without the programmer
specifying it, but I think it still counts as a bug.

Before reporting it, cut it down to a minimum test case, something like:

#include <stdio.h>
#include <assert.h>
#include <complex.h>
#include <tgmath.h>

int foo(int x) {
return abs(x);
}

Then remove the header lines until you get the missing prototype warning.

[Chris M. Thomasson]

^^^^^^^^^^^^^^^^^^^^^^

Ummmm. Why in the heck am I not using the dis variable for the condition
wrt comparing the radius of z as being greater than 256

damn it!? I am calling cabs twice here. Crap. Okay. Change the if above to

if (dis > 256.0)

Sorry.

[Mark Storkamp]

In article <oeanu2$rbb$1...@dont-email.me>,

"Chris M. Thomasson" <inv...@invalid.invalid> wrote:

> On 5/1/2017 10:27 PM, Chris M. Thomasson wrote:
> > This compiler just helped me find a bug that compiled right along wrt
> > GCC 5.1.0 on windows even using: -Wall -pedantic -Wextra -Wall
> [...]
>
> Fwiw, here is my first step at the following code comprised of a single
> file Plain PPM generating fractal renderer. Can anybody find any crap in
> here, fwiw compiles clean on both lcc-win and my gcc:
>
> ** Be warned **, the code creates an output file called
> ct_ffe_cipher.ppm. Can you run and open the file in a graphics editor?
> It works for me with the Gimp. This non-sense with the hardcoded file
> name will change to gain data in the arguments from the command line in
> my next iteration of the code. Sorry about the crude state. ;^o
>

Works for me on OS X 10.4.11 with gcc 4.0.1. Opens with GraphicConverter
V5.9.4 and Gimp 2.2.

[Chris M. Thomasson]

^^^^^^^^^^^^^^^^^^^^^^^^^

I should floor, ceil or round the sum, then cast the result to unsigned
int. Strange that I get no warnings for this!

[Chris M. Thomasson]

Thank you so much your valuable time wrt to giving it a go, I am glad it
works for you. This Mandelbrot coloring is considered "pretty", unlike
the following garbage:

https://groups.google.com/d/topic/sci.crypt/xytM7aFRfjQ/discussion

https://plus.google.com/101799841244447089430/posts/NtH5sBDpy7H

Try to find the green from the image with all red... ;^)

The puzzle is the ultimate goal for this portable renderer.

[Chris M. Thomasson]

On 5/1/2017 10:27 PM, Chris M. Thomasson wrote:

> This compiler just helped me find a bug that compiled right along wrt
> GCC 5.1.0 on windows even using: -Wall -pedantic -Wextra -Wall
>
> Take a look at the following c99 crude code and try to find the bug:
> ____________________

[...]

> int main(void)
> {
> ct_iterate_plane(73, 73, 53);
>
> fflush(stdout);
> printf("\n\nFin, hit <ENTER> to exit...\n");
> getchar();

^^^^^^^^^^^^^^^^^^^

Ummm.... What the hell am I doing putting the damn fflush _before_ that
damn final printf, before the getchar!?

Damn it! It has to be like this:

printf("\n\nFin, hit <ENTER> to exit...\n");

fflush(stdout);
getchar();

SHI%. Thank god this is still version 0.0.0.0 (pre-alpha)

Ouch! ;^o

[Ben Bacarisse]

"Chris M. Thomasson" <inv...@invalid.invalid> writes:

> On 5/2/2017 11:25 AM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <inv...@invalid.invalid> writes:
>>
>>> This compiler just helped me find a bug that compiled right along wrt
>>> GCC 5.1.0 on windows even using: -Wall -pedantic -Wextra -Wall
>>
>> My gcc (slightly newer) tells me that abs is not declared even with no
>> -W arguments. Don't you get that?
>>
>>> Take a look at the following c99 crude code and try to find the bug:
>>
>> Did you tell gcc this is c99 code? I ask because I am wondering why I
>> get the warning and you don't.
>
> The full command line that CodeBlocks IDE passes to the GCC compiler is:
>
> x86_64-w64-mingw32-gcc.exe -Wall -pedantic -Wextra -Wall -std=c99 -g -c
> C:\Users\Chris\Documents\MingW\ct_c_test\main.c -o obj\Debug\main.o
>
> It gives no warnings when abs is used. I notice that -Wall is used
> twice, it must be an artifact of the IDE.
>
> The version of gcc I am using is: gcc version 5.1.0 (tdm64-1) from:
>
> http://tdm-gcc.tdragon.net

That looks like a bug. I see David Brown has some useful advice so I
won't duplicate.

<snip>
--
Ben.

[bartc]

On 02/05/2017 06:27, Chris M. Thomasson wrote:

> The problem is my call to abs! I need to be using cabs and lcc-win64
> found it for me.

I tried it and it said there was no prototype for abs(). Same with one
or two other compilers.

This should be standard: a missing prototype for a function should be an
error, as it is otherwise crazy for it to assume that any non-declared
function takes int arguments and returns an int result.

And was cabs suggested? Pelles C suggested using fabs().

--
bartc

[Chris M. Thomasson]

Imvvho, I personally think that using cabs is "clearer" wrt getting the
radius of a complex number.

[Chris M. Thomasson]

It has to be a bug. No warning at all!

Will post a bug report when I get some more time. Working on the cipher
part of my portable PPM renderer. Having a lot of fun as well! :^)

[Chris M. Thomasson]

Will do, thanks David. I need to work on this plotter in the meantime.

[Ben Bacarisse]

"Chris M. Thomasson" <inv...@invalid.invalid> writes:

> On 5/2/2017 12:53 PM, Chris M. Thomasson wrote:

<snip>

>> if (cabs(z) > 256.0)
>> {
>> double sum = (i + 1) * (i + .01) * 123U;
>> unsigned int red = sum;
> ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> I should floor, ceil or round the sum, then cast the result to
> unsigned int. Strange that I get no warnings for this!

There's no need to cast (there's very rarely any need to cast).

You can often ask for a warning about this sort of thing. It's not
usually turned on by default because of the number of "false" positives
(too many harmless cases). In gcc it's -Wconversion.

<snip>
--
Ben.

[bartc]

It's not a bug. I have gcc/tdm 5.1.0 as well; the code includes
tgmath.h. tgmath.h includes math.h. math.h contains these lines:

#ifndef _CRT_ABS_DEFINED
#define _CRT_ABS_DEFINED
int __cdecl abs(int _X);
long __cdecl labs(long _X);
#endif

If I comment out the abs declaration, then I get this:

c:\c>\tdm\bin\gcc -Wextra -Wall -Wpedantic d.c
d.c: In function 'ct_iterate_pixel':
d.c:19:13: warning: implicit declaration of function 'abs'
[-Wimplicit-function-declaration]
if (abs(z) > 2)
^
Otherwise nothing.

--
bartc

[Ben Bacarisse]

bartc <b...@freeuk.com> writes:

> On 03/05/2017 00:04, Chris M. Thomasson wrote:
>> On 5/2/2017 3:56 PM, Ben Bacarisse wrote:
>
>>> That looks like a bug. I see David Brown has some useful advice so I
>>> won't duplicate.
>>
>> It has to be a bug. No warning at all!
>>
>> Will post a bug report when I get some more time. Working on the cipher
>> part of my portable PPM renderer. Having a lot of fun as well! :^)
>
> It's not a bug. I have gcc/tdm 5.1.0 as well; the code includes tgmath.h. tgmath.h includes math.h. math.h contains these lines:
>
> #ifndef _CRT_ABS_DEFINED
> #define _CRT_ABS_DEFINED
> int __cdecl abs(int _X);
> long __cdecl labs(long _X);
> #endif

I don't think math.h should declare abs. The standard says it is
declared in stdlib.h. That makes it a bug unless there is some wording
I've missed that permits math.h to declare the integer abs functions.

<snip>
--
Ben.

[Keith Thompson]

bartc <b...@freeuk.com> writes:
> On 03/05/2017 00:04, Chris M. Thomasson wrote:
>> On 5/2/2017 3:56 PM, Ben Bacarisse wrote:
>>> That looks like a bug. I see David Brown has some useful advice so I
>>> won't duplicate.
>>
>> It has to be a bug. No warning at all!
>>
>> Will post a bug report when I get some more time. Working on the cipher
>> part of my portable PPM renderer. Having a lot of fun as well! :^)
>
> It's not a bug. I have gcc/tdm 5.1.0 as well; the code includes
> tgmath.h. tgmath.h includes math.h. math.h contains these lines:
>
> #ifndef _CRT_ABS_DEFINED
> #define _CRT_ABS_DEFINED
> int __cdecl abs(int _X);
> long __cdecl labs(long _X);
> #endif

That would appear to be a non-conforming implementation of the <math.h>
header, unless those lines are excluded when compiling in conforming
mode. (It doesn't appear to be a bug in gcc; the compiler itself seems
to be behaving as it should given the incorrect header.)

The standard says that <tgmath.h> includes <math.h> and <complex.h> and
defines several type-generic macros. But <math.h> does not declare
abs() or labs(); those are declared in <stdlib.h> (along with llabs();
perhaps you have a pre-C99 header).

A simplified version of the original program:

#include <tgmath.h>
int main(void) {
double complex z = 0;
z = abs(z);
}

A conforming implementation must diagnose the call to the undeclared
function abs().

There are 9 absolute value functions in the C standard library:

<stdlib.h>
int abs(int j);
long int labs(long int j);
long long int llabs(long long int j);

<math.h>
double fabs(double x);
float fabsf(float x);
long double fabsl(long double x);

<complex.h>
double cabs(double complex z);
float cabsf(float complex z);
long double cabsl(long double complex z);

<tgmath.h> defines the type-generic macro fabs(), which can expand to a
call to any of the absolute value functions in <math.h> or <complex.h>
but *not* to the functions in <stdlib.h> (N1570 7.25p4).

You could fix the above simplified program by changing
z = abs(z);
to either
z = fabs(z);
which invokes the macro from <tgmath.h> or
z = cabs(z);
which calls the cabs() function declared in <math.h>, which is included
from <tgmath.h>. The difference is that cabs() is not type-generic.
If z is of type long double complex, cabs() may lose precision, but
fabs() will not.

It might have been a nice idea for <tgmath.h> to define both fabs()
(type-generic over the floating-point and complex types) and cabs()
(type-generic over just the complex types).

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[David Brown]

That's my reading of the standard too.

So to me, this looks like a bug in the header <math.h>. It is not a bug
in gcc itself.

Where does tdm get its headers like <math.h> ? It looks to me that it
is from the mingw project (mingw or mingw-64 - I am not sure).

[Scott Lurndal]

"Chris M. Thomasson" <inv...@invalid.invalid> writes:

>On 5/1/2017 10:27 PM, Chris M. Thomasson wrote:
>> This compiler just helped me find a bug that compiled right along wrt
>> GCC 5.1.0 on windows even using: -Wall -pedantic -Wextra -Wall
>>
>> Take a look at the following c99 crude code and try to find the bug:
>> ____________________
>[...]
>> int main(void)
>> {
>> ct_iterate_plane(73, 73, 53);
>>
>> fflush(stdout);
>> printf("\n\nFin, hit <ENTER> to exit...\n");
>> getchar();
>^^^^^^^^^^^^^^^^^^^
>
>Ummm.... What the hell am I doing putting the damn fflush _before_ that
>damn final printf, before the getchar!?

Why are you using fflush at all? If stdout is interactive
(isatty() != 0), the stream is line-buffered and the newline
will trigger a flush.

If it is not interactive (isatty() == 0), then you can set the
stream to line-buffered using setvbuf(3).

[supe...@casperkitty.com]

On Wednesday, May 3, 2017 at 8:23:25 AM UTC-5, Scott Lurndal wrote:
> Why are you using fflush at all? If stdout is interactive
> (isatty() != 0), the stream is line-buffered and the newline
> will trigger a flush.
>
> If it is not interactive (isatty() == 0), then you can set the
> stream to line-buffered using setvbuf(3).

Code which uses setvbuf(3) will be limited to systems which support
POSIX or the console-related portions thereof, while uses fflush()
will be supported on all conforming hosted C implementations. Further,
stdout may sometimes be routed to things that the system doesn't see
as interactive consoles, but which should nonetheless behave like them
(e.g. a program which requests raw input from stdin and displays it on
a grid of LEDs). Using fflush() in such cases may help ensure that
data gets delivered in timely fashion even if the system doesn't think
the output is an interactive console.

[Chris M. Thomasson]

On 5/1/2017 10:27 PM, Chris M. Thomasson wrote:
> This compiler just helped me find a bug that compiled right along wrt
> GCC 5.1.0 on windows even using: -Wall -pedantic -Wextra -Wall
>
> Take a look at the following c99 crude code and try to find the bug:

[...]

> The problem is my call to abs! I need to be using cabs and lcc-win64
> found it for me.
>
> Thank you Jacob Navia!

Fwiw, here is a link to a new version of my renderder that outputs a
cheat sheet in actual static garbage cipher colors:

https://github.com/ChrisMThomasson/fractal_cipher/blob/master/FFE/ffe.c

Read all of:

https://groups.google.com/d/topic/sci.crypt/xytM7aFRfjQ/discussion

For further context on the reason why I am working on this.

[Chris M. Thomasson]

Great point! I should create a typedef for the type of floating point
the code is using. fabs is the right call. Thank you.

[Tim Rentsch]

supe...@casperkitty.com writes:

> On Wednesday, May 3, 2017 at 8:23:25 AM UTC-5, Scott Lurndal wrote:
>> Why are you using fflush at all? If stdout is interactive
>> (isatty() != 0), the stream is line-buffered and the newline
>> will trigger a flush.
>>
>> If it is not interactive (isatty() == 0), then you can set the
>> stream to line-buffered using setvbuf(3).
>
> Code which uses setvbuf(3) will be limited to systems which support

> POSIX or the console-related portions thereof, [...]

The setvbuf function has been part of standard C since at least
the original ANSI standard.