Discussion:
Many thanks to lcc-win...
(too old to reply)
Chris M. Thomasson
2017-05-02 05:27:15 UTC
Permalink
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
2017-05-02 05:33:17 UTC
Permalink
Post by 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
____________________
[...]
Post by Chris M. Thomasson
____________________
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!
Post by Chris M. Thomasson
Thank you Jacob Navia!
:^)
David Brown
2017-05-02 07:44:33 UTC
Permalink
Post by Chris M. Thomasson
Post by 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
____________________
[...]
Post by Chris M. Thomasson
____________________
The problem is my call to abs! I need to be using cabs and lcc-win64
found it for me.
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).

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.
Post by Chris M. Thomasson
Post by Chris M. Thomasson
Thank you Jacob Navia!
:^)
Chris M. Thomasson
2017-05-02 18:29:16 UTC
Permalink
Post by David Brown
Post by Chris M. Thomasson
Post by 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
____________________
[...]
Post by Chris M. Thomasson
____________________
The problem is my call to abs! I need to be using cabs and lcc-win64
found it for me.
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
Post by David Brown
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)
Post by David Brown
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.
Mark Storkamp
2017-05-02 14:00:18 UTC
Permalink
Post by 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
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'"
Chris M. Thomasson
2017-05-02 18:25:48 UTC
Permalink
Post by Mark Storkamp
Post by 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
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'"
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?
David Brown
2017-05-02 19:59:19 UTC
Permalink
Post by Chris M. Thomasson
Post by Mark Storkamp
Post by 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
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'"
lcc-win gives the same: missing prototype for abs
gcc version 5.1.0 (tdm64-1)
does not give any warning whatsoever. Humm, should I try to report this
anomaly?
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
2017-05-02 23:17:49 UTC
Permalink
Post by David Brown
Post by Chris M. Thomasson
Post by Mark Storkamp
Post by 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
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'"
lcc-win gives the same: missing prototype for abs
gcc version 5.1.0 (tdm64-1)
does not give any warning whatsoever. Humm, should I try to report this
anomaly?
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.
#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.
Will do, thanks David. I need to work on this plotter in the meantime.
Ben Bacarisse
2017-05-02 18:25:14 UTC
Permalink
Post by 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
My gcc (slightly newer) tells me that abs is not declared even with no
-W arguments. Don't you get that?
Did you tell gcc this is c99 code? I ask because I am wondering why I
get the warning and you don't.
Post by Chris M. Thomasson
____________________
#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>
Post by Chris M. Thomasson
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
2017-05-02 18:43:06 UTC
Permalink
Post by Ben Bacarisse
Post by 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
My gcc (slightly newer) tells me that abs is not declared even with no
-W arguments. Don't you get that?
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


[...]
Post by Ben Bacarisse
Post by Chris M. Thomasson
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.
Ben Bacarisse
2017-05-02 22:56:44 UTC
Permalink
Post by Chris M. Thomasson
Post by Ben Bacarisse
Post by 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
My gcc (slightly newer) tells me that abs is not declared even with no
-W arguments. Don't you get that?
Did you tell gcc this is c99 code? I ask because I am wondering why I
get the warning and you don't.
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.
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.
Chris M. Thomasson
2017-05-02 23:04:56 UTC
Permalink
Post by Ben Bacarisse
Post by Chris M. Thomasson
Post by Ben Bacarisse
Post by 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
My gcc (slightly newer) tells me that abs is not declared even with no
-W arguments. Don't you get that?
Did you tell gcc this is c99 code? I ask because I am wondering why I
get the warning and you don't.
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.
http://tdm-gcc.tdragon.net
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! :^)
bartc
2017-05-02 23:49:59 UTC
Permalink
Post by Chris M. Thomasson
Post by Ben Bacarisse
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

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
2017-05-03 00:54:32 UTC
Permalink
Post by bartc
Post by Chris M. Thomasson
Post by Ben Bacarisse
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! :^)
#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.
David Brown
2017-05-03 09:31:49 UTC
Permalink
Post by Ben Bacarisse
Post by bartc
Post by Chris M. Thomasson
Post by Ben Bacarisse
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! :^)
#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>
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).
Keith Thompson
2017-05-03 01:10:57 UTC
Permalink
Post by bartc
Post by Chris M. Thomasson
Post by Ben Bacarisse
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
#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) kst-***@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"
Chris M. Thomasson
2017-05-03 23:23:36 UTC
Permalink
Post by Keith Thompson
Post by bartc
Post by Chris M. Thomasson
Post by Ben Bacarisse
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
#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).
#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().
<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.
Great point! I should create a typedef for the type of floating point
the code is using. fabs is the right call. Thank you.
Post by Keith Thompson
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).
Chris M. Thomasson
2017-05-02 19:53:40 UTC
Permalink
Post by 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
[...]

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?
Chris M. Thomasson
2017-05-02 20:19:07 UTC
Permalink
Post by Chris M. Thomasson
Post by 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
[...]
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
** 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
_______________________
/* 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)
^^^^^^^^^^^^^^^^^^^^^^

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.
Post by Chris M. Thomasson
{
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?
Mark Storkamp
2017-05-02 20:35:09 UTC
Permalink
Post by Chris M. Thomasson
Post by 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
[...]
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
** 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
2017-05-02 20:51:58 UTC
Permalink
Post by Mark Storkamp
Post by Chris M. Thomasson
Post by 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
[...]
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
** 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.
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
2017-05-02 20:49:16 UTC
Permalink
Post by Chris M. Thomasson
Post by 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
[...]
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
** 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
_______________________
/* 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;
^^^^^^^^^^^^^^^^^^^^^^^^^

I should floor, ceil or round the sum, then cast the result to unsigned
int. Strange that I get no warnings for this!
Post by Chris M. Thomasson
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?
Ben Bacarisse
2017-05-02 23:20:42 UTC
Permalink
<snip>
Post by Chris M. Thomasson
Post by Chris M. Thomasson
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.
Chris M. Thomasson
2017-05-02 21:13:56 UTC
Permalink
Post by 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
____________________
[...]
Post by Chris M. Thomasson
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
Post by Chris M. Thomasson
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!
:^)
Scott Lurndal
2017-05-03 13:23:16 UTC
Permalink
Post by Chris M. Thomasson
Post by 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
____________________
[...]
Post by Chris M. Thomasson
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).
s***@casperkitty.com
2017-05-03 16:30:30 UTC
Permalink
Post by Scott Lurndal
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.
Tim Rentsch
2017-05-05 10:00:23 UTC
Permalink
Post by s***@casperkitty.com
Post by Scott Lurndal
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.

bartc
2017-05-02 22:58:07 UTC
Permalink
Post by Chris M. Thomasson
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
2017-05-02 23:01:36 UTC
Permalink
Post by bartc
Post by Chris M. Thomasson
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().
Imvvho, I personally think that using cabs is "clearer" wrt getting the
radius of a complex number.
Chris M. Thomasson
2017-05-03 23:20:31 UTC
Permalink
Post by 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
[...]
Post by Chris M. Thomasson
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.
Loading...