Math failure?? (Rick failure??) with optimizations enabled

[Rick C. Hodgin]

I have a failure in both GCC and MSVC in Release mode, but the code
works properly in Debug mode with optimizations disabled. This very
error has plagued me since the beginning of my Visual FreePro
project. I assume there is something happening that I am not aware
of in Release mode, which is different than Debug mode code
generation without optimizations. I've tried compiling using SSE2
and different settings for the FPU. When I compile with FPU:strict
in release mode it gets the closest, where sometimes it work
correctly on some of the test node lines. Other times it fails.
the same behavior is seen in both GCC 4.8.1 and VS2008's MSVC
compiler.

Source code:

http://pastebin.com/Vxxf8MXE

In this example, it creates a graphic file called output.bmp. That
file contains segments comprising a two-part bezier line from the
upper-left to the lower-right drawn in rectangle segments.

In MSVC it compiles in debug mode, and generates the correct image.
In release mode it generates an empty output file in this test file.
In the actual application it generates an output file with incorrect
lines positioned about. As the mouse moves around, it will redraw
sometimes closer to correct, other times not correct.

In GCC it compiles in debug mode, and generates the correct image.
In release mode it generates the same correct image in this little
test file, but in the actual project it generates the same type of
output as MSVC, but with slightly different results than MSVC's as
the lines don't shift quite as much, but are still incorrect.

This is a pretty large sample. If anybody wants to take a look at
it I would appreciate your guidance. I have had a few other similar
errors comparing debug mode results to release mode results that I
also have not been able to determine the cause of. Perhaps any
findings here will help me out there as well.

Thank you in advance.

Best regards,
Rick C. Hodgin

-----
MSVC compile string (compiled in c:\temp\math_failure\):

Debug:
cl /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Gm /EHsc /RTC1 /MDd /Zp1 /Fo"Debug\\" /Fd"Debug\vc90.pdb" /W3 /nologo /c /ZI /TP /errorReport:prompt
link /OUT:"c:\temp\math_failure\Debug\math_failure.exe" /INCREMENTAL /NOLOGO /MANIFEST /MANIFESTFILE:"Debug\math_failure.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"c:\temp\math_failure\Debug\math_failure.pdb" /SUBSYSTEM:CONSOLE /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:PROMPT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

Release:
cl /O2 /Oi /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /FD /EHsc /MD /Zp1 /Gy /Fo"Release\\" /Fd"Release\vc90.pdb" /W3 /nologo /c /Zi /TP /errorReport:prompt
link /OUT:"c:\temp\math_failure\Release\math_failure.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"Release\math_failure.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"c:\temp\math_failure\Release\math_failure.pdb" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /LTCG /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:PROMPT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

-----
GCC compile string:

Debug:
C:\MinGW-4.8.1\bin\gcc.exe -c "c:/temp/math_failure/math_failure.c" -g -O0 -Wall -fpack-struct=1 -o ./Debug/math_failure.c.o -I.
C:\MinGW-4.8.1\bin\g++.exe -o ./Debug/math_failure_mingw @"math_failure_mingw.txt" -L.

Release:
C:\MinGW-4.8.1\bin\gcc.exe -c "c:/temp/math_failure/math_failure.c" -O2 -Wall -fpack-struct=1 -DNDEBUG -o ./Release/math_failure.c.o -I.
C:\MinGW-4.8.1\bin\g++.exe -o ./Release/math_failure_mingw @"math_failure_mingw.txt" -L.

[Rick C. Hodgin]

I have been able to verify that VS2003 exhibits the same type of problem,
though the results are different under default fp consistency. Under
improved fp consistency it is similar, but still different than VS2008
and GCC.

[JohnF]

Rick C. Hodgin <rick.c...@gmail.com> wrote:
> I have a failure in both GCC and MSVC in Release mode,
> but the code works properly in Debug mode with
> optimizations disabled.

Is -O3 (or what?) optimization the only difference
between "release" and "debug" mode, or do you have some
-mdebug (or what?) switches, too? What happens when -O3
is the only difference (using your choice of fpu both times)?
Oh, I see your lines...

> Debug:
> C:\MinGW-4.8.1\bin\gcc.exe -c "c:/temp/math_failure/math_failure.c"
> -g -O0 -Wall -fpack-struct=1 -o ./Debug/math_failure.c.o -I.
> C:\MinGW-4.8.1\bin\g++.exe -o ./Debug/math_failure_mingw
> @"math_failure_mingw.txt" -L.
> Release:
> C:\MinGW-4.8.1\bin\gcc.exe -c "c:/temp/math_failure/math_failure.c"
-O2 -Wall -fpack-struct=1 -DNDEBUG -o ./Release/math_failure.c.o -I.
> C:\MinGW-4.8.1\bin\g++.exe -o ./Release/math_failure_mingw
> @"math_failure_mingw.txt" -L.

The -fpack-struct stands out. You maybe getting a little too tricky
for your own good? Maybe the optimization gets tricked?

> http://pastebin.com/Vxxf8MXE
> In this example, it creates a graphic file called output.bmp. That
> file contains segments comprising a two-part bezier line from the
> upper-left to the lower-right drawn in rectangle segments.

I took a quick look (suggestion below), mainly out of curiosity about
your "rectangle segments" remark. I see your iBmp_drawArbitraryQuad()
function, but can't quite make heads or tails out of it.
What's your algorithm for that??? It looks to me like maybe you're
drawing lots of one-pixel-wide adjacent lines to fill the rectangle's
tnwidth? Or something like that? I had a similar problem, but
none of the "rectangle fill" stuff I googled addressed it exactly.
They're always replacing a background pixel color with another,
defining an edge when the background color changes, not filling a
geometrically defined rectangular area (regardless of its current
background color).

Anyway, for your problem, I think your sample code's too complex.
You really want to solve it? Cut it down to size -- construct
a "minimum working [or non-working in this case] example"
that demonstrates the problem. Then debug that. Probably lots
of work to build that minimum example, but I think that's what
you've got to do.
--
John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )

[Rick C. Hodgin]

I have been able to verify that the same happens in VS98 as well.
However, due to a misstep by me during the setup for testing, I
forgot to set structure alignment to 1-byte packed. In VS98 it
defaults to 8-byte aligned, and it almost worked. The math
wasn't quite correct, so I tried 16-byte aligned and it looked
the same as 8-byte aligned. Switching to 1-byte packed and it
produces even different results than any of the others, but at
least the results in VS98 are entirely symmetric. The results
for the others seem symmetric in the upper-left, but in the lower-
right are completely skewed.

I find this very interesting.

[Rick C. Hodgin]

On Saturday, November 8, 2014 9:58:00 PM UTC-5, JohnF wrote:
> Rick C. Hodgin <rick.c...@gmail.com> wrote:
> > Debug:
> > C:\MinGW-4.8.1\bin\gcc.exe -c "c:/temp/math_failure/math_failure.c"
> > -g -O0 -Wall -fpack-struct=1 -o ./Debug/math_failure.c.o -I.
> > C:\MinGW-4.8.1\bin\g++.exe -o ./Debug/math_failure_mingw
> > @"math_failure_mingw.txt" -L.
> > Release:
> > C:\MinGW-4.8.1\bin\gcc.exe -c "c:/temp/math_failure/math_failure.c"
> -O2 -Wall -fpack-struct=1 -DNDEBUG -o ./Release/math_failure.c.o -I.
> > C:\MinGW-4.8.1\bin\g++.exe -o ./Release/math_failure_mingw
> > @"math_failure_mingw.txt" -L.
> The -fpack-struct stands out. You maybe getting a little too tricky
> for your own good? Maybe the optimization gets tricked?

For .BMP file I/O the structures have to be packed to 1-byte alignment.
So, I just pack everything.

> > http://pastebin.com/Vxxf8MXE
> > In this example, it creates a graphic file called output.bmp. That
> > file contains segments comprising a two-part bezier line from the
> > upper-left to the lower-right drawn in rectangle segments.
>
> I took a quick look (suggestion below), mainly out of curiosity about
> your "rectangle segments" remark. I see your iBmp_drawArbitraryQuad()
> function, but can't quite make heads or tails out of it.
> What's your algorithm for that??? It looks to me like maybe you're
> drawing lots of one-pixel-wide adjacent lines to fill the rectangle's
> tnwidth?

I provide that algorithm a starting and ending point which is the line
segment, but it is not drawn:

----------

In order to make it a quad, I do draw up and down portions at the ends:

|---------|

And then I connect the top portion and the button portion:
_________
|_________|

That creates the quad. The points are (tnX1,tnY1) to (tnX2,tnY2) for
the source. Those are integers. I then use those, and the data
computed for the slope of the line, and the perpendicular slope, to
determine the tick points on either side:

p1 p3
| |
|----------------------|
| |
p2 p4

I then draw p1 to p2 and p3 to p4 if they want end-caps. And then I
draw p1 to p3, and p2 to p4.

[Barry Schwarz]

Does it matter that you gave the file a cpp extension so MSVC will
compile it as C++?

--
Remove del for email

[JohnF]

Rick C. Hodgin <rick.c...@gmail.com> wrote:
> On Saturday, November 8, 2014 9:58:00 PM UTC-5, JohnF wrote:
>> Rick C. Hodgin <rick.c...@gmail.com> wrote:
>> > Debug:
>> > C:\MinGW-4.8.1\bin\gcc.exe -c "c:/temp/math_failure/math_failure.c"
>> > -g -O0 -Wall -fpack-struct=1 -o ./Debug/math_failure.c.o -I.
>> > C:\MinGW-4.8.1\bin\g++.exe -o ./Debug/math_failure_mingw
>> > @"math_failure_mingw.txt" -L.
>> > Release:
>> > C:\MinGW-4.8.1\bin\gcc.exe -c "c:/temp/math_failure/math_failure.c"
>> -O2 -Wall -fpack-struct=1 -DNDEBUG -o ./Release/math_failure.c.o -I.
>> > C:\MinGW-4.8.1\bin\g++.exe -o ./Release/math_failure_mingw
>> > @"math_failure_mingw.txt" -L.
>> The -fpack-struct stands out. You maybe getting a little too tricky
>> for your own good? Maybe the optimization gets tricked?
>
> For .BMP file I/O the structures have to be packed to 1-byte alignment.
> So, I just pack everything.

Yeah, the .bmp file has to be packed. Forget C structs!!!
You think maybe I don't know that for sure??? See my
http://www.forkosh.com/gifsave89.zip (/gifsave89.html for discussion)
and look at the gifsave89.c program. (You can see a listing by clicking
the "gifsave89 listing" link under the Contents of the html page.)
In particular, look at the
putblkbytes() function (line#1860 of the listing), and the
controlgif() function (line#976).
controlgif represents a gif block that one would be >>tempted<< to
define as a struct containing each element comprising the block.
Then you'd just assign values to those elements, and write
sizeof(struct controlgif) bytes, making sure the struct was packed.
But that's just >>not safe<< and not portable, which I learned
the hard (very hard) way, pretty much exactly like you're doing now.
Instead, look at what I do in controlgif()... call putblkbyte()
(or several of its "friends", one for each possible datatype)
for each element of the struct. That is, controlgif() is called
precisely when you'd otherwise want to write sizeof(struct controlgif)
bytes. Except the function call works reliably by memcpy()'ing the stuff,
using utility functions like that putblkbytes() to hide/encapsulate
the low-level details. That way, controlgif()'s code (and all the similar
functions in gifsave89) looks pretty much in one-to-one correspondence
with the would-be-struct, e.g., line#'s 1006-1013...
1006: status = putblkbyte(bk,Introducer);
1007: if ( OKAY ) status = putblkbyte(bk,Label);
1008: if ( OKAY ) status = putblkbyte(bk,BlockSize);
1009: if ( OKAY ) status = putblkbyte(bk,Packed);
1010: if ( OKAY ) status = putblkword(bk,delay);
1011: if ( OKAY ) status = putblkbyte(bk,(tcolor<0?0:tcolor));
1012: if ( OKAY ) status = putblkbyte(bk,Terminator);
1013: if ( OKAY ) gs->ncontrol++; /* count (another?) graphic control*/
So the struct would have just had elements Introducer, Label, etc.
It's still a much bigger pain this way, but that's what you >>have<< to do.
Well, you don't >>have<< to, but you know what happens if you dont:)

>> > http://pastebin.com/Vxxf8MXE
>> > In this example, it creates a graphic file called output.bmp. That
>> > file contains segments comprising a two-part bezier line from the
>> > upper-left to the lower-right drawn in rectangle segments.
>>
>> I took a quick look (suggestion below), mainly out of curiosity about
>> your "rectangle segments" remark. I see your iBmp_drawArbitraryQuad()
>> function, but can't quite make heads or tails out of it.
>> What's your algorithm for that??? It looks to me like maybe you're
>> drawing lots of one-pixel-wide adjacent lines to fill the rectangle's
>> tnwidth?

Thanks for the algorithm below, Rick. I see you're not filling
the quad/rectangle, but rather drawing its outline (I'd been
expecting some kind of loop in your iBmp_drawArbitraryQuad()
for filling; now I know why I didn't see it:).

> I provide that algorithm a starting and ending point which is the line
> segment, but it is not drawn:
> ----------
> In order to make it a quad, I do draw up and down portions at the ends:
> |---------|
> And then I connect the top portion and the button portion:
> _________
> |_________|
> That creates the quad. The points are (tnX1,tnY1) to (tnX2,tnY2) for
> the source. Those are integers. I then use those, and the data
> computed for the slope of the line, and the perpendicular slope, to
> determine the tick points on either side:
> p1 p3
> | |
> |----------------------|
> | |
> p2 p4
> I then draw p1 to p2 and p3 to p4 if they want end-caps. And then I
> draw p1 to p3, and p2 to p4.
> Best regards, Rick C. Hodgin

[Geoff]

On Sat, 08 Nov 2014 20:01:12 -0800, Barry Schwarz <schw...@dqel.com>
wrote:

>Does it matter that you gave the file a cpp extension so MSVC will
>compile it as C++?

VC2010 actually /won't/ compile it, yielding error C2632 on line 40
due to the typedef int bool line. If you look closely at his command
lines he's not naming it .cpp in practice, in spite of his
documentation in the source. His VC2008 would fail as well since bool
was a valid type from VS2003 onward so his gyrations in lines 39-49
are unnecessary.

[BartC]

"Rick C. Hodgin" <rick.c...@gmail.com> wrote in message
news:19c5fe23-17b4-4331...@googlegroups.com...

> Source code:
>
> http://pastebin.com/Vxxf8MXE

Wow, you seem to like stringing things out! From iBmp_allocate in main() to
where it actually sets up the header info is about 4 functions deep.

Also, if this is designed for Windows, I'm not sure why you are redefining
the various bitmap structs which are available in windows.h, for
portability?.

Anyway, the BFH struct needs to be 14 bytes in size. You're defining it as
16 bytes (in my gcc/32-bit compiler anyway), and writing 16 bytes.

(So the output file doesn't load properly, with a program I've used for
years to load BMPs with no problem.)

Look carefully at other MS structs too: many have odd sizes, some will also
have 32-bit fields misaligned on 16-bit boundaries.

--
Bartc

[Ben Bacarisse]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:

> I have a failure in both GCC and MSVC in Release mode, but the code
> works properly in Debug mode with optimizations disabled. This very
> error has plagued me since the beginning of my Visual FreePro
> project. I assume there is something happening that I am not aware
> of in Release mode, which is different than Debug mode code
> generation without optimizations. I've tried compiling using SSE2
> and different settings for the FPU. When I compile with FPU:strict
> in release mode it gets the closest, where sometimes it work
> correctly on some of the test node lines. Other times it fails.
> the same behavior is seen in both GCC 4.8.1 and VS2008's MSVC
> compiler.

Yes, the code has undefined behaviour. When fixed, gcc produces the
same output at all optimisation levels (where it didn't before). Sounds
like the bug you report, though one can never be absolutely sure.
However, since I am an agent of Satan, you may prefer to find the bug
yourself.

<snip>
--
Ben.

[Rick C. Hodgin]

Barry Schwarz wrote:
> Does it matter that you gave the file a cpp
> extension so MSVC will compile it as C++?

No. Same thing. I wrote this as a C version to
see if that was it. The real version is here:

https://github.com/RickCHodgin/libsf/commit/f63cfeae15e31ec192802e04d4fc45c59a707cc3

If you run it as of that commit, yoi'll see the
results in debug and release builds. See the
libsf/source/vjr/ directory.

[Rick C. Hodgin]

Geoff wrote:
> His VC2008 would fail as well since bool was
> a valid type from VS2003 onward so his
> gyrations in lines 39-49 are unnecessary.

It compiles as is in VS98, VS2003, VS2008, and
MinGW 4.8.1.

The math_failure.cpp comment was added by
the Visual Studio project/solution wizard. I
didn't think to change it. But it is a C file, not
CPP.

I haven't tested in VS2010 or later.

[Rick C. Hodgin]

Bartc wrote:
> Also, if this is designed for Windows, I'm not
> sure why you are redefining the various
> bitmap structs which are available in
> windows.h, for portability?

I copied it from the Windows header file for
this example. People should be able to compile
without a Windows machine.

In VS98, VS2003, VS2008, and MinGW GCC 4.8.1,
it compiles properly and writes a valid output.bmp
file. I'll test it in Linux.

The various algorithms are taken from Visual
FreePro and Visual FreePro, Jr. and exist as they
do because they are primitive functions used
throughout.

[jacob navia]

Le 09/11/2014 13:38, Ben Bacarisse a écrit :
> I am an agent of Satan

Nice to know Ben.

And you do that full time or as a part-time job only?

:-)

[BartC]

"Rick C. Hodgin" <rick.c...@gmail.com> wrote in message

news:2f18b565-c870-4b58...@googlegroups.com...

> Bartc wrote:
>> Also, if this is designed for Windows, I'm not
>> sure why you are redefining the various
>> bitmap structs which are available in
>> windows.h, for portability?
>
> I copied it from the Windows header file for
> this example. People should be able to compile
> without a Windows machine.

I tried all my six or so Windows compilers, and they all give the BFH size
as 16 bytes.

Because of the misaligned bfSize element, you'd expect any compiler to move
it along 2 more bytes, and that will push the size up to 16.

But after sticking #pragma pack(1) in there, the size becomes 14 bytes and
the BMP file is now valid. (NOTE: the code might fail when misaligned
accesses cause an exception; a different, more reliable approach is needed
to write the BMP header in the correct format.)

What would be interesting is to find out how you managed to produce a
working BMP file at all; what size of BFH do you get without any pragma
controls?

--
Bartc

[Ben Bacarisse]

It occurs to me that others might spend time on this so here is the bug
I found, obscured with rot13, so Rick can avoid looking if he so
chooses.

Inevbhf vafgnaprf bs gur fgehpgher FYvarS32 ner hfrq havgvnyvfrq. Gur
shapgvba vviiz_pbclYvar pnyyf vviiz_zngu_pbzchgrYvar gb svyy-va fbzr
rkgen qrgnvyf, ohg fvapr gur syntf hfrq gb fnl juvpu rkgenf ner arrqrq
unir arire orra frg, gurl jvyy be jvyy abg or pbzchgrq onfrq ba
vaqrgrezvangr qngn. Sbepvat nyy zrzore gb or pbzchgrq rirel gvzr (abg
gur evtug svk bs pbhefr, ohg n cebbs bs pbaprcg) znxrf gur pbqr orunir
cerqvpgnoyl.

--
Ben.

[Rick C. Hodgin]

On Sunday, November 9, 2014 8:20:33 AM UTC-5, Bart wrote:
> "Rick C. Hodgin" <rick.c...@gmail.com> wrote in message
> news:2f18b565-c870-4b58...@googlegroups.com...
> > Bartc wrote:
> >> Also, if this is designed for Windows, I'm not
> >> sure why you are redefining the various
> >> bitmap structs which are available in
> >> windows.h, for portability?
> >
> > I copied it from the Windows header file for
> > this example. People should be able to compile
> > without a Windows machine.
>
> I tried all my six or so Windows compilers, and they all give the BFH size
> as 16 bytes.

Look at my compiler flags in the first post. Are you compiling with /Zp1?
I have the structures packed in my compiler flags.

And in GCC you need -fpack-struct=1 for one-byte alignment.

> What would be interesting is to find out how you managed to produce a
> working BMP file at all; what size of BFH do you get without any pragma
> controls?

[Rick C. Hodgin]

I figured it out (without Ben's rot13 message). SLine32 is not initialized
before use. In Debug mode it is populated by particular values. In Release
mode it has whatever is on the stack.

http://pastebin.com/ZpMWDNpN

[BartC]

"Rick C. Hodgin" <rick.c...@gmail.com> wrote in message

news:ade7cb1b-1b10-4012...@googlegroups.com...

> On Sunday, November 9, 2014 8:20:33 AM UTC-5, Bart wrote:

>> I tried all my six or so Windows compilers, and they all give the BFH
>> size
>> as 16 bytes.
>
> Look at my compiler flags in the first post. Are you compiling with /Zp1?
> I have the structures packed in my compiler flags.

You mean the compiler flags as in:

"Release:
cl /O2 /Oi /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D
"UNICODE" /FD /EHsc /MD /Zp1 /Gy /Fo"Release\\" /Fd"Release\vc90.pdb" /W3
/nologo /c /Zi /TP /errorReport:prompt
link /OUT:"c:\temp\math_failure\Release\math_failure.exe" /INCREMENTAL:NO
/NOLOGO /MANIFEST
/MANIFESTFILE:"Release\math_failure.exe.intermediate.manifest"
/MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG
/PDB:"c:\temp\math_failure\Release\math_failure.pdb" /SUBSYSTEM:CONSOLE
/OPT:REF /OPT:ICF /LTCG /DYNAMICBASE /NXCOMPAT /MACHINE:X86
/ERRORREPORT:PROMPT kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib

odbc32.lib odbccp32.lib"?

If so then I must have overlooked that part of your post...

(BTW I don't think forcing 1-byte packing on *all* structs in a module is a
good solution to the problem. Even if the hardware and/or compiler can deal
with the misalignments. And even if it was, relying on
implementation-specific compiler flags (or pragmas) is not a good way of
doing that.)

--
Bartc

[Rick C. Hodgin]

Ben, you would be of great benefit to LibSF. If
you would ever humble yourself and bring your
skills as an offering unto others, in recognition
of Who it was who first gave you those innate
abilities, the opportunities to learn, grow, excel,
and share all you possess with others, the
purpose of which is to improve their lives by the
blessings you've received, then you would be
welcomed into the project.

Kaz, Bart, David, others, you also would be
welcomed...

[Malcolm McLean]

On Sunday, November 9, 2014 1:02:13 PM UTC, Rick C. Hodgin wrote:
>
> I copied it from the Windows header file for
> this example. People should be able to compile
> without a Windows machine.
>
> In VS98, VS2003, VS2008, and MinGW GCC 4.8.1,
> it compiles properly and writes a valid output.bmp
> file. I'll test it in Linux.
>
> The various algorithms are taken from Visual
> FreePro and Visual FreePro, Jr. and exist as they
> do because they are primitive functions used
> throughout.
>

Never write a C struct to a binary file using fwrite, unless it's a temporary
file that will be read in again by the same version of the same program.

It's easy enough to knock up functions to write 16 and 32 bit integers,
a little bit more difficult to read due to sign extension and the fact that
shifting by more than the width of an integer is technically undefined.

I've got portable IEE 754 binary read write routines for floating point numbers,
but they aren't relevant for BMP files.

[Rick C. Hodgin]

On Sunday, November 9, 2014 10:47:14 AM UTC-5, Malcolm McLean wrote:
> Never write a C struct to a binary file using fwrite, unless it's a
> temporary file that will be read in again by the same version of the
> same program.

Why?

[Geoff]

Watch out for the dreaded copy-paste bug:

memset(&l1, 0, sizeof(l1));
memset(&l2, 0, sizeof(l2));
l1.trig = true;
l2.trig = true;

[BartC]

"Rick C. Hodgin" <rick.c...@gmail.com> wrote in message

news:e1caf953-c608-46a1...@googlegroups.com...

> On Sunday, November 9, 2014 10:47:14 AM UTC-5, Malcolm McLean wrote:
>> Never write a C struct to a binary file using fwrite, unless it's a
>> temporary file that will be read in again by the same version of the
>> same program.
>
> Why?

Presumably because of differences in element type widths and padding of the
struct (and endianness) between the program which writes it (directly from
the bytes in the struct), and the program that will read it (byte-by-byte
into its version of the struct).

I think it can be done if it can be guaranteed the two versions of the
struct will be compatible (but I don't agree with using obscure
compile-switches to ensure that).

Malcolm is suggesting reading or writing field-by-field, then the layout of
the struct in memory is not crucial. (If the struct has to match something
inside Win32, that's another matter.)

--
Bartc

[Rick C. Hodgin]

On Sunday, November 9, 2014 11:21:38 AM UTC-5, Geoff wrote:
> Watch out for the dreaded copy-paste bug:
>
> memset(&l1, 0, sizeof(l1));
> memset(&l2, 0, sizeof(l2));
> l1.trig = true;
> l2.trig = true;

I don't know what the dreaded copy-paste bug is.

[Geoff]

On Sun, 9 Nov 2014 08:36:32 -0800 (PST), "Rick C. Hodgin"
<rick.c...@gmail.com> wrote:

>On Sunday, November 9, 2014 11:21:38 AM UTC-5, Geoff wrote:
>> Watch out for the dreaded copy-paste bug:
>>
>> memset(&l1, 0, sizeof(l1));
>> memset(&l2, 0, sizeof(l2));
>> l1.trig = true;
>> l2.trig = true;
>
>I don't know what the dreaded copy-paste bug is.
>

You wrote:
memset(&l1, 0, sizeof(l1));

memset(&l2, 0, sizeof(l1));

[Rick C. Hodgin]

On Sunday, November 9, 2014 11:34:32 AM UTC-5, Bart wrote:
> Malcolm is suggesting reading or writing field-by-field, then the layout of
> the struct in memory is not crucial. (If the struct has to match something
> inside Win32, that's another matter.)

Makes sense. The BMP file format is explicitly little-endian, and is
of this fixed type for file formats (though there are extensions based
on the definition of biSize in the BIH portion.

As for me, I came from a DOS background migrating later to Windows and
Win32. The development I do relates to Win32 peculiarities in many
areas. Here the SBitmap structure contains the bi member. This member
is used by a crucial function to all of my internal graphic manipulation,
which is CreateDIBSection(). It uses that format explicitly to create
the Device-Independent-Bitmap format.

I am currently trying to remove those as I move toward a fully OpenGL
presentation. We'll see how it goes though. A few hurdles remain.
Am working on them this weekend, though Friday night my truck broke
down and I wound up waiting until after 3pm on Saturday to have AAA
come and tow it three miles. :-) Cost me about a day of development.

Anyone know where the EEC is located on a 1991 Ford F-150? :-)

[Rick C. Hodgin]

LOL! Oops. :-)

In my development, I do about 15 of those kinds of mistakes per hour.
It's one of the reasons I place such a high value on edit-and-continue
debugging. I don't know why I make those kinds of mistakes. They are
not in my mind that way, but they translate through my mind into the
outward things my hands wield with those kinds of mistakes throughout.
I often go back and read the things I've written here on these forums
and find I miss words, use the wrong word, etc. I think if I were to
assess my own postings on those kinds of common mistakes I would brand
myself to be an idiot. But, inside of my thoughts they are not that
way, and I don't know how or why things get lost like that in the
translation. It happens in all areas of my life, and I'm almost always
surprise thereafter that something wound up being "published" the way
it was published with those kinds of mistakes. I've spent hours
searching for bugs that only existed for those reasons, and not because
I had a mistake in understanding the algorithm in my mind. It's really
something.

This one was interesting too because when I modified math_failure.c
for reposting I made that mistake. But in my actual implementation I
went back in and duplicated those efforts. In the actual implementation
I had done it correctly. :-)

There's actually also a mistake I found in typing in on the actual
implementation, which relates to the lmid variable. It also is not
initialized and should be.

memset(&lmid, 0, sizeof(lmid));
lmid.trig = true;

[Rick C. Hodgin]

On Sunday, November 9, 2014 11:51:13 AM UTC-5, Rick C. Hodgin wrote:
> In my development, I do about 15 of those kinds of mistakes per hour.

See ... even here. I meant 15 of those kinds of mistakes per day.

It's really something. It has days where it's worse than other days
as well. Today I'm feeling like I may be getting sick after waiting
outside in the cold so long yesterday for AAA. :-(

[Chris M. Thomasson]

> "Rick C. Hodgin" wrote in message
> news:19c5fe23-17b4-4331...@googlegroups.com...

> I have a failure in both GCC and MSVC in Release mode, but the code
> works properly in Debug mode with optimizations disabled. This very
> error has plagued me since the beginning of my Visual FreePro
> project. I assume there is something happening that I am not aware
> of in Release mode, which is different than Debug mode code
> generation without optimizations. I've tried compiling using SSE2
> and different settings for the FPU. When I compile with FPU:strict
> in release mode it gets the closest, where sometimes it work
> correctly on some of the test node lines. Other times it fails.
> the same behavior is seen in both GCC 4.8.1 and VS2008's MSVC
> compiler.

> Source code:

> http://pastebin.com/Vxxf8MXE

This code compiles with:
_____________________________________
#ifndef _CRT_SECURE_NO_WARNINGS
# define _CRT_SECURE_NO_WARNINGS
#endif
_____________________________________

placed at the beginning of the source file. However,
`output.bmp' is not a correct bitmap. For instance,
I cannot open it in ms paint; it says its an invalid bitmap.
FWIW, here is a simple library in C++ that works for me:

http://easybmp.sourceforge.net

This can be converted to pure C.

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message
> news:m3oh84$e89$1...@speranza.aioe.org...

> > "Rick C. Hodgin" wrote in message
> > news:19c5fe23-17b4-4331...@googlegroups.com...

[...]

> > Source code:
> > http://pastebin.com/Vxxf8MXE
> This code compiles with:
_____________________________________
> #ifndef _CRT_SECURE_NO_WARNINGS
> # define _CRT_SECURE_NO_WARNINGS
> #endif
> _____________________________________

Sorry for forgetting to mention that I used MSVC
2013 as a compiler!

;^o

[David Brown]

On 09/11/14 17:31, BartC wrote:
>
>
> "Rick C. Hodgin" <rick.c...@gmail.com> wrote in message
> news:e1caf953-c608-46a1...@googlegroups.com...
>> On Sunday, November 9, 2014 10:47:14 AM UTC-5, Malcolm McLean wrote:
>>> Never write a C struct to a binary file using fwrite, unless it's a
>>> temporary file that will be read in again by the same version of the
>>> same program.
>>
>> Why?
>
> Presumably because of differences in element type widths and padding of
> the struct (and endianness) between the program which writes it
> (directly from the bytes in the struct), and the program that will read
> it (byte-by-byte into its version of the struct).
>
> I think it can be done if it can be guaranteed the two versions of the
> struct will be compatible (but I don't agree with using obscure
> compile-switches to ensure that).

If you use size-specific types (uint16_t, int32_t, etc.), make sure
everything is naturally aligned (i.e., 4-byte items are 4-byte aligned),
then you are unlikely to meet portability problems. If you also add
compile-time checks (static assertions) on the size of the structure and
the endianness, and avoid bitfields (unless you also add checks for
them), then your code will give the same structure in virtually every
case - or a compile-time failure if something is not supported.

(I say "virtually" every case, as there may be obscure systems using
something like one's complement integers or non-IEEE floating point that
cause trouble.)

[Geoff]

On Sun, 9 Nov 2014 12:02:16 -0800, "Chris M. Thomasson"
<n...@spam.invalid> wrote:

>> "Rick C. Hodgin" wrote in message
>> news:19c5fe23-17b4-4331...@googlegroups.com...
>
>> I have a failure in both GCC and MSVC in Release mode, but the code
>> works properly in Debug mode with optimizations disabled. This very
>> error has plagued me since the beginning of my Visual FreePro
>> project. I assume there is something happening that I am not aware
>> of in Release mode, which is different than Debug mode code
>> generation without optimizations. I've tried compiling using SSE2
>> and different settings for the FPU. When I compile with FPU:strict
>> in release mode it gets the closest, where sometimes it work
>> correctly on some of the test node lines. Other times it fails.
>> the same behavior is seen in both GCC 4.8.1 and VS2008's MSVC
>> compiler.
>
>> Source code:
>
>> http://pastebin.com/Vxxf8MXE
>
>This code compiles with:
>_____________________________________
>#ifndef _CRT_SECURE_NO_WARNINGS
># define _CRT_SECURE_NO_WARNINGS
>#endif
>_____________________________________
>

It will compile OK without that. This only suppresses the warnings
about "unsafe" functions like fopen and unless you treat warnings as
errors it will compile.

>placed at the beginning of the source file. However,
>`output.bmp' is not a correct bitmap. For instance,
>I cannot open it in ms paint; it says its an invalid bitmap.

As noted elsewhere in the thread, you must use /Zp1 in the command
line. (Struct Member Alignment) in the Code Generation property page
in the IDE, or #pragma pack(1) in the source to get the BFH structure
to be sized properly to 14 bytes, then the bitmap will load in your
viewer.

[Chris M. Thomasson]

> "Geoff" wrote in message
> news:3umv5a1gp7qeom38j...@4ax.com...

> > On Sun, 9 Nov 2014 12:02:16 -0800, "Chris M. Thomasson"
> > <n...@spam.invalid> wrote:
> >> "Rick C. Hodgin" wrote in message
> >> news:19c5fe23-17b4-4331...@googlegroups.com...
> >

[...]

> >
> >> Source code:
> >
> >> http://pastebin.com/Vxxf8MXE
> >
> >This code compiles with:
> >_____________________________________
> >#ifndef _CRT_SECURE_NO_WARNINGS
> ># define _CRT_SECURE_NO_WARNINGS
> >#endif
> >_____________________________________
> >

> It will compile OK without that. This only suppresses the warnings
> about "unsafe" functions like fopen and unless you treat warnings as
> errors it will compile.

Quite right. I have warning set as errors!

> >placed at the beginning of the source file. However,
> >`output.bmp' is not a correct bitmap. For instance,
> >I cannot open it in ms paint; it says its an invalid bitmap.

> As noted elsewhere in the thread, you must use /Zp1 in the command
> line. (Struct Member Alignment) in the Code Generation property page
> in the IDE, or #pragma pack(1) in the source to get the BFH structure
> to be sized properly to 14 bytes, then the bitmap will load in your
> viewer.

Ahh, I totally missed that Geoff!

Let me try it out...

[Rick C. Hodgin]

On Sunday, November 9, 2014 5:06:51 PM UTC-5, Chris M. Thomasson wrote:
> > "Geoff" wrote in message
> > news:3umv5a1gp7qeom38j...@4ax.com...

> > > On Sun, 9 Nov 2014 12:02:16 -0800, "Chris M. Thomasson" wrote:
> > >> http://pastebin.com/Vxxf8MXE
> > >
> > >This code compiles with:
> > >_____________________________________
> > >#ifndef _CRT_SECURE_NO_WARNINGS
> > ># define _CRT_SECURE_NO_WARNINGS
> > >#endif
> > >_____________________________________
> > >
>
> > It will compile OK without that. This only suppresses the warnings
> > about "unsafe" functions like fopen and unless you treat warnings as
> > errors it will compile.
>
> Quite right. I have warning set as errors!

I was going to ask you about that. I haven't used any versions of
Visual Studio beyond 2010 except for trying 2012 at one point. I
couldn't remember about it and I as thinking maybe VS2013 actually
required that it be defined.

[Chris M. Thomasson]

> "Rick C. Hodgin" wrote in message

> news:16540b26-38fa-45fb...@googlegroups.com...

> > > On Sunday, November 9, 2014 5:06:51 PM UTC-5, Chris M. Thomasson
> > > wrote:

[...]

> > > It will compile OK without that. This only suppresses the warnings
> > > about "unsafe" functions like fopen and unless you treat warnings as
> > > errors it will compile.
> >
> > Quite right. I have warning set as errors!

> I was going to ask you about that. I haven't used any versions of
> Visual Studio beyond 2010 except for trying 2012 at one point. I
> couldn't remember about it and I as thinking maybe VS2013 actually
> required that it be defined.

Actually, I do not know the answer to that because I set
warnings to error by default; it’s a habit. So, I have to
turn that off in order to get an answer to your query.

:^o

[Chris M. Thomasson]

> > "Chris M. Thomasson" wrote in message

> > news:m3orb3$8fp$1...@speranza.aioe.org...

> "Rick C. Hodgin" wrote in message

> news:16540b26-38fa-45fb...@googlegroups.com...

> > > On Sunday, November 9, 2014 5:06:51 PM UTC-5, Chris M. Thomasson
> > > wrote:

[...]

> > > It will compile OK without that. This only suppresses the warnings
> > > about "unsafe" functions like fopen and unless you treat warnings as
> > > errors it will compile.
> >
> > Quite right. I have warning set as errors!

> I was going to ask you about that. I haven't used any versions of
> Visual Studio beyond 2010 except for trying 2012 at one point. I
> couldn't remember about it and I as thinking maybe VS2013 actually
> required that it be defined.

This creates a valid bitmap with /Zp1. Also, it still generates an error
even with the `warnings as errors' option turned off. So, AFAICT,
MSVC 2013 requires `_CRT_SECURE_NO_WARNINGS' to be defined
if you use something like `fopen'.

[Rick C. Hodgin]

On Sunday, November 9, 2014 6:01:08 PM UTC-5, Chris M. Thomasson wrote:
> > Rick C. Hodgin wrote:

> > > "Chris M. Thomasson" wrote:
> > > Quite right. I have warning set as errors!
> > I was going to ask you about that. I haven't used any versions of
> > Visual Studio beyond 2010 except for trying 2012 at one point. I
> > couldn't remember about it and I as thinking maybe VS2013 actually
> > required that it be defined.
>
> This creates a valid bitmap with /Zp1. Also, it still generates an error
> even with the `warnings as errors' option turned off. So, AFAICT,
> MSVC 2013 requires `_CRT_SECURE_NO_WARNINGS' to be defined
> if you use something like `fopen'.

Interesting. I typically use fopen() because I write code which
compiles in both GCC and MSVC.

Best regards,
Rick C. Hhodgin

[Malcolm McLean]

On Sunday, November 9, 2014 9:50:26 PM UTC, David Brown wrote:
>
> > I think it can be done if it can be guaranteed the two versions of the
> > struct will be compatible (but I don't agree with using obscure
> > compile-switches to ensure that).
>
> If you use size-specific types (uint16_t, int32_t, etc.), make sure
> everything is naturally aligned (i.e., 4-byte items are 4-byte aligned),
> then you are unlikely to meet portability problems. If you also add
> compile-time checks (static assertions) on the size of the structure and
> the endianness, and avoid bitfields (unless you also add checks for
> them), then your code will give the same structure in virtually every
> case - or a compile-time failure if something is not supported.
>
> (I say "virtually" every case, as there may be obscure systems using
> something like one's complement integers or non-IEEE floating point that
> cause trouble.)
>

Endianness causes the worst problems. Probably not if you know that
the code will always run on a version of the same processor, but
certainly if you want to port.
Then string or char fields might be padded differently but still to
a multiple of 4 bytes.
Also if the binary file is defined in terms of a C struct, then a
reader needs to #include the header to get that struct. But that might
pull in all sorts of unwanted items.

[Geoff]

I used this to hack the packing problem, this pragma is compatible
between current MSVC, GCC, LLVM. This struct is well-defined as 14
bytes for a long time and the structure MS defines in WinGDI.h
actually uses internal headers called pshpack2.h and poppack.h to do
different forms of it conditionally according to their compiler
version in use.

#pragma pack(push)
#pragma pack(2)
typedef struct tagBmpFileHeader {
WORD bfType;
DWORD bfSize;
WORD bfReserved1;
WORD bfReserved2;
DWORD bfOffBits;
} BFH;
#pragma pack (pop)

[glen herrmannsfeldt]

BartC <b...@freeuk.com> wrote:

>> On Sunday, November 9, 2014 10:47:14 AM UTC-5, Malcolm McLean wrote:
>>> Never write a C struct to a binary file using fwrite, unless it's a
>>> temporary file that will be read in again by the same version of the
>>> same program.

(snip)

> Presumably because of differences in element type widths and padding of the
> struct (and endianness) between the program which writes it (directly from
> the bytes in the struct), and the program that will read it (byte-by-byte
> into its version of the struct).

> I think it can be done if it can be guaranteed the two versions of the
> struct will be compatible (but I don't agree with using obscure
> compile-switches to ensure that).

Well, compiled with the same version of the same compiler should be
good enough.

> Malcolm is suggesting reading or writing field-by-field, then the
> layout of the struct in memory is not crucial. (If the struct has
> to match something inside Win32, that's another matter.)

Well, that won't fix endian differences or width differences.

But I agree, using struct for example as a file system directory
format, you will later find a different system, different compiler,
or even different version of the same compiler, that changes it.

Reasonably often, though, I know two programs will be compiled
with the same compiler, and that it will work.

-- glen

[Richard Heathfield]

glen herrmannsfeldt wrote:

> BartC <b...@freeuk.com> wrote:
>
>>> On Sunday, November 9, 2014 10:47:14 AM UTC-5, Malcolm McLean wrote:
>>>> Never write a C struct to a binary file using fwrite, unless it's a
>>>> temporary file that will be read in again by the same version of the
>>>> same program.
>
> (snip)
>
>> Presumably because of differences in element type widths and padding of
>> the struct (and endianness) between the program which writes it (directly
>> from the bytes in the struct), and the program that will read it
>> (byte-by-byte into its version of the struct).
>
>> I think it can be done if it can be guaranteed the two versions of the
>> struct will be compatible (but I don't agree with using obscure
>> compile-switches to ensure that).
>
> Well, compiled with the same version of the same compiler should be
> good enough.
>
>> Malcolm is suggesting reading or writing field-by-field, then the
>> layout of the struct in memory is not crucial. (If the struct has
>> to match something inside Win32, that's another matter.)
>
> Well, that won't fix endian differences or width differences.

That's why I read bitmap data byte by byte, and build my own integers.

static unsigned long read_bytes(FILE *fp, int bytes)
{
unsigned long val = 0;
int ch = 0;
int i = 0;
assert(bytes <= 4);

while(i < bytes)
{
ch = getc(fp);
val |= ch << (8 * i++);
}
return val;
}

static int write_bytes(FILE *fp, unsigned long int dw, int bytes)
{
assert(bytes <= 4);
while(bytes--)
{
putc(dw & 0xFF, fp);
dw >>= 8;
}
return ferror(fp);
}

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[Ike Naar]

On 2014-11-09, Rick C. Hodgin <rick.c...@gmail.com> wrote:
> I have a failure in both GCC and MSVC in Release mode, but the code
> works properly in Debug mode with optimizations disabled. This very
> error has plagued me since the beginning of my Visual FreePro
> project. I assume there is something happening that I am not aware
> of in Release mode, which is different than Debug mode code
> generation without optimizations. I've tried compiling using SSE2
> and different settings for the FPU. When I compile with FPU:strict
> in release mode it gets the closest, where sometimes it work
> correctly on some of the test node lines. Other times it fails.
> the same behavior is seen in both GCC 4.8.1 and VS2008's MSVC
> compiler.
>
> Source code:
>
> http://pastebin.com/Vxxf8MXE

Undefined behaviour.
For one, in iivvm_math_computeLine(), line->trig is never initialized.

[David Brown]

I can't speak for any of the others, but there is no way I would ever
consider contributing to "LibSF" (in its current form) or even using the
products. I am happy to discuss interesting C-related issues in a
public forum like this - and while RDC-related ideas are strictly
speaking off-topic in comp.lang.c, they have led to some enjoyable
threads that make a nice change from dissecting the wording of the C
standards (which can be useful and important, but is seldom fun).

But I have two major reasons why I would not work with "LibSF" or your
other projects - one technical, and one non-technical.

On the technical side, I don't think the project is useful - either to
me, or to anyone else. I don't agree with your edit-and-continue
debugging and development methodology - I think it is rarely a good
development strategy, and in the cases that it might be useful, there
are better tools already. I don't think the world needs "RDC" or your
other languages - I don't think they are well designed, and they do not
fulfil any needs of developers.

The project is like someone building their own car - for the builder, it
is a labour of love that they enjoy and learn from, but it is never
going to be practical even for their own use, and certainly it is of no
use to anyone else. And just as I'd be happy to chat with the car
builder, offer advice (if I knew anything about cars!) or lend a tool,
but I would not get involved in building it, so to am I happy to talk
with you here but I would not get involved in your project.


The non-technical issue is /you/. There is no way I could work with
you. You are a fanatic - and I mean that in the negative sense. If you
want to centre your life around Jesus and your beliefs, that's fine -
but until you can do so without pushing away everyone else, then you
will find it very hard to get others to work with you. You need to
learn that "love thy neighbour" includes "/respect/ thy neighbour", and
that the way to encourage others to see the world your way is through
your peace, strength, and dedication to those close to you (such as your
family) - not through out-of-context quotations, fire-and-brimstone
preaching, failed rationalisations and blaming everything on unseen enemies.


I also have a family and a more-than-full-time job - I don't have time
enough to contribute to the projects that I think are important and
interesting, so I certainly don't have time to spend on something like
your project.

But I am happy to discuss things here - just as I am happy to discuss
any other project or thread that comes up in this group, if it is
something that interests me and I think I can add to the discussion (or
ask useful questions). Discussing RDC has made me think about some new
ideas, and I hope it has helped you and perhaps others here - which is
what newsgroups are for.

[mark.b...@gmail.com]

On Sunday, 9 November 2014 13:16:06 UTC, jacob navia wrote:
> Le 09/11/2014 13:38, Ben Bacarisse a écrit :
> > I am an agent of Satan
>
> Nice to know Ben.
>
> And you do that full time or as a part-time job only?

And what are the commission rates like?

[David Brown]

On 10/11/14 00:23, Malcolm McLean wrote:
> On Sunday, November 9, 2014 9:50:26 PM UTC, David Brown wrote:
>>
>>> I think it can be done if it can be guaranteed the two versions of the
>>> struct will be compatible (but I don't agree with using obscure
>>> compile-switches to ensure that).
>>
>> If you use size-specific types (uint16_t, int32_t, etc.), make sure
>> everything is naturally aligned (i.e., 4-byte items are 4-byte aligned),
>> then you are unlikely to meet portability problems. If you also add
>> compile-time checks (static assertions) on the size of the structure and
>> the endianness, and avoid bitfields (unless you also add checks for
>> them), then your code will give the same structure in virtually every
>> case - or a compile-time failure if something is not supported.
>>
>> (I say "virtually" every case, as there may be obscure systems using
>> something like one's complement integers or non-IEEE floating point that
>> cause trouble.)
>>
> Endianness causes the worst problems. Probably not if you know that
> the code will always run on a version of the same processor, but
> certainly if you want to port.

Yes, endianness is the most annoying - and it is also, as far as I know,
impossible to test for at compile-time in a completely standard way.
Compilers usually have pre-defined macros which can be tested, but they
are compiler-specific such as gcc:

#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
...
#endif

There are not even standard functions (or macros) for swapping
endianness - the nearest I know of is the "hton" family, which are
commonly available but don't help if you are on a big-endian target.

One compiler I used long ago had direct support for endianness with
something along the lines of:

#pragma(bigendian)
uint32_t be_X;

Very useful when you had to deal with mixed endian data.

> Then string or char fields might be padded differently but still to
> a multiple of 4 bytes.

Padding is easier to handle - if you stick to natural alignments, it is
rare that extra padding is added. And it is easy to check to total
structure size with a compile-time assertion - then you don't have any
hidden problems.

> Also if the binary file is defined in terms of a C struct, then a
> reader needs to #include the header to get that struct. But that might
> pull in all sorts of unwanted items.
>

Yes, such headers should be kept to a minimum, and use only other
standard headers (such as <stdint.h>).

[mark.b...@gmail.com]

On Sunday, 9 November 2014 15:39:26 UTC, Rick C. Hodgin wrote:
> Ben, you would be of great benefit to LibSF. If
> you would ever humble yourself and bring your
> skills as an offering unto others, in recognition
> of Who it was who first gave you those innate
> abilities, the opportunities to learn, grow, excel,
> and share all you possess with others, the
> purpose of which is to improve their lives by the
> blessings you've received, then you would be
> welcomed into the project.

To paraphrase (and distort) Groucho, I doubt Ben would wish to join a club that would have you...

[glen herrmannsfeldt]

Richard Heathfield <inv...@see.sig.invalid> wrote:

(snip, I wrote)

>> Well, that won't fix endian differences or width differences.

> That's why I read bitmap data byte by byte, and build my own integers.

It gets more interesting if the machine doesn't define bytes in
the same way.

For example, on machines with 36 bit words.

But yes, bitmaps should be defined in terms of bytes and
written/read that way.

-- glen

[Malcolm McLean]

On Monday, November 10, 2014 9:35:16 AM UTC, glen herrmannsfeldt wrote:
> Richard Heathfield <inv...@see.sig.invalid> wrote:
>
> (snip, I wrote)
>

> > That's why I read bitmap data byte by byte, and build my own integers.
>
> It gets more interesting if the machine doesn't define bytes in
> the same way.
>
> For example, on machines with 36 bit words.
>
> But yes, bitmaps should be defined in terms of bytes and
> written/read that way.
>

You have to assume that if one machine writes 8 bit bytes, another machine will retrieve
the same 8 bit value with a call to fgetc().
Then everything is fine.

It's a bit trickily to handle weirdness appropriately.
I think this should work regardless of machine representation, even if we go for fibonnaci
base phi numbers.
/*
read a 16 bit big-endian signed integer from a stream,
store in 2's complement format.
*/
int fget16be(FILE *fp)
{
int ch;
int neg = 0;
unsigned int answer = 0;

ch = fgetc(fp);
if(ch & 0x80)
neg = 1;
answer = neg ? ~ch : ch;
answer *= 256;
ch = fgetc(fp);
answer += neg ? ~ch : ch;
if(neg)
answer++;
return neg ? -answer : answer;
}

In reality assuming two's complement is portable enough.

[Richard Heathfield]

Malcolm McLean wrote:

> In reality assuming two's complement is portable enough

You don't have to assume two's complement if you use unsigned integer types.

[BartC]

"glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message
news:m3pcff$7np$1...@speranza.aioe.org...

> BartC <b...@freeuk.com> wrote:

>> I think it can be done if it can be guaranteed the two versions of the
>> struct will be compatible (but I don't agree with using obscure
>> compile-switches to ensure that).
>
> Well, compiled with the same version of the same compiler should be
> good enough.

No it won't. We are talking about two different programs. Even if they share
the same struct definition via a common header file, how it's compiled
depends on the exact compiler options used, as well as which headers have
come before, which may define types differently, or use a different struct
packing mode.

>> Malcolm is suggesting reading or writing field-by-field, then the
>> layout of the struct in memory is not crucial. (If the struct has
>> to match something inside Win32, that's another matter.)
>
> Well, that won't fix endian differences or width differences.

You can read or write an N-byte field from a file with more certainty than
trusting that sizeof(T)==N, where T could be the result of several nested
typedefs, some of which are hidden away in someone else's header (and which
may well also depend on some compiler switch or macro).

It won't automatically deal with endianness, but once a problem is
identified, is easier to deal with this way.

> But I agree, using struct for example as a file system directory
> format, you will later find a different system, different compiler,
> or even different version of the same compiler, that changes it.
>
> Reasonably often, though, I know two programs will be compiled
> with the same compiler, and that it will work.

In the case of a file format, the programs that write and read it, could be
running on totally different computers, perhaps from different eras (you
should know about this), and could be written in different languages.

I don't think anyway that a general purpose binary file format or header
should be defined in terms of a set of C struct fields (such as BMP seems
largely to be). It should be independent of the vagaries of such a language.

--
Bartc

[Malcolm McLean]

On Monday, November 10, 2014 11:09:33 AM UTC, Bart wrote:
>
> In the case of a file format, the programs that write and read it, could be
> running on totally different computers, perhaps from different eras (you
> should know about this), and could be written in different languages.
>
> I don't think anyway that a general purpose binary file format or header
> should be defined in terms of a set of C struct fields (such as BMP seems
> largely to be). It should be independent of the vagaries of such a language.
>

Microsoft don't like to think that anyone could possibly ever want to read
a .bmp file in a non-Windows program. Which was almost true for a period.

[Rick C. Hodgin]

David Brown wrote:
> [snip]

The offer remains open to you and the others
should you ever have a change of heart.

[Ben Bacarisse]

Malcolm McLean <malcolm...@btinternet.com> writes:
<snip>

> I think this should work regardless of machine representation, even if
> we go for fibonnaci base phi numbers.
> /*
> read a 16 bit big-endian signed integer from a stream,
> store in 2's complement format.

You mean "stored" yes?

> */
> int fget16be(FILE *fp)
> {
> int ch;
> int neg = 0;
> unsigned int answer = 0;
>
> ch = fgetc(fp);
> if(ch & 0x80)
> neg = 1;
> answer = neg ? ~ch : ch;
> answer *= 256;
> ch = fgetc(fp);
> answer += neg ? ~ch : ch;
> if(neg)
> answer++;
> return neg ? -answer : answer;
> }

No.

--
Ben.

[Malcolm McLean]

You're right.
I've got a compiler now, and tested it.
Of course the last bit doesn't fall off if unsigned int isn't 16 bits.

[Ben Bacarisse]

It doesn't work when unsigned int is 16 bits either.

--
Ben.

[Malcolm McLean]

This one's been tested.
It was failure to mask the character after inverting it.

int fget16be(FILE *fp)
{
int ch;
int neg = 0;
unsigned int answer = 0;

ch = fgetc(fp);
if(ch & 0x80)
neg = 1;

answer = neg ? ~ch & 0xFF : ch;

answer *= 256;
ch = fgetc(fp);

answer += neg ? ~ch & 0xFF: ch;

[Richard Bos]

"BartC" <b...@freeuk.com> wrote:

> I don't think anyway that a general purpose binary file format or header
> should be defined in terms of a set of C struct fields (such as BMP seems
> largely to be). It should be independent of the vagaries of such a language.

Oh, BMP is _worse_. It's dependent on the vagaries of the OS internals.
With (d)evolving OS versions _and_ increased graphics capabilities and
user demands, it's had to collect rather a bit of cruft over the years.

Richard

[Richard Bos]

Malcolm McLean <malcolm...@btinternet.com> wrote:

> On Monday, November 10, 2014 9:35:16 AM UTC, glen herrmannsfeldt wrote:
> > Richard Heathfield <inv...@see.sig.invalid> wrote:
> >
> > (snip, I wrote)
> >
> > > That's why I read bitmap data byte by byte, and build my own integers.
> >
> > It gets more interesting if the machine doesn't define bytes in
> > the same way.
> >
> > For example, on machines with 36 bit words.
> >
> > But yes, bitmaps should be defined in terms of bytes and
> > written/read that way.
> >
> You have to assume that if one machine writes 8 bit bytes, another machine will retrieve
> the same 8 bit value with a call to fgetc().

Which is why file formats should really be defined in terms of _octets_,
or explicit-length _and_ explicit-endianness larger units, ideally made
up of octets.

(It's hard, even if not impossible, to define a file format that's
portable to devices that don't use a multiple-of-eight size byte; hard
enough that in the general case it's not worth the trouble.)

Richard

[JohnF]

David Brown <david...@hesbynett.no> wrote:
> <<snip>> I don't think the world needs "RDC" or your

> other languages - I don't think they are well designed,
> and they do not fulfil any needs of developers.
> The project is like someone building their own car -
> for the builder, it is a labour of love that they enjoy
> and learn from,

Yes, precisely, I learned exactly the same lesson from
my own "little language" www.forkosh.com/nutshell.html
(and various other projects) that nobody but me has
any use for. But I think you're being a bit too negative,
or at least projecting a bit of a too-negative feeling.
"Enjoy and learn from" should be your central theme here.
You could develop your remarks into a really good essay
about how to become a talented programmer. Programming
to other people's specs doesn't do it alone.

> but it is never going to be practical even for their own use,
> and certainly it is of no use to anyone else.
> And just as I'd be happy to chat with the car
> builder, offer advice (if I knew anything about cars!)
> or lend a tool, but I would not get involved in building it,
> so to am I happy to talk with you here but I would not get

> involved in your project. <<snip>>
--
John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )

[JohnF]

David Brown <david...@hesbynett.no> wrote:
> endianness is the most annoying - and it is also, as far as I know,
> impossible to test for at compile-time in a completely standard way.
> Compilers usually have pre-defined macros which can be tested, but they
> are compiler-specific

> There are not even standard functions (or macros) for swapping
> endianness - the nearest I know of is the "hton" family

> commonly available but don't help if you are on a big-endian target.

I think I got around endianness issues in the following portable way,
letting arithmetic operations identify which byte is which...
#define BYTE unsigned char
int putblkword ( BYTE *blk, int offset, int word ) {
int putblkbytes(); /* write sequence of bytes */
/* --- byte values regardless of little/big-endian ordering on host --- */
int lobyte = (abs(word))%256, /* least significant byte */
hibyte = ((abs(word))/256)%256; /* next least significant byte */
BYTE thisword[2]; /* buffer for word's bytes */
/* --- store little-endian ordering (least significant byte first) --- */
thisword[0] = ((BYTE)lobyte); /* low-order byte written first */
thisword[1] = ((BYTE)hibyte); /* high-order byte written second */
return ( putblkbytes(blk,offset,thisword,2) ); /* put thisword at offset */
}
You see any situations where that strategy would fail?

[JohnF]

David Brown <david...@hesbynett.no> wrote:
> <<snip>> Padding is easier to handle -

> if you stick to natural alignments,
> it is rare that extra padding is added.

Yeah, to me it seems like a major C shortcoming that
packed structs aren't reliably and portably available.
C, sometimes called a "portable assembly language",
is often used for the kind of low-level stuff that needs
this kind of feature. Instead, you typically have to
write each member of a struct individually, according
to its sizeof(member).
But it's clear that a struct containing consecutive
members, say, unsigned char bytes[37]; double x;
may require some architecture-dependent padding.
But C could provide a stdlib-like function packstruct(),
typically called just prior to i/o (or just output),
that removes any padding, returning a packed sequence
of bytes. And a corresponding unpackstruct() for input.
You could do it yourself on a struct-by-struct
basis using offsetof() and sizeof(). Just check
offsetof(next_member)-offsetof(member) against
sizeof(member). If the offsetof difference is
larger than the sizeof, you know there's padding.
Even easier, you could memcpy each member's sizeof
bytes into a sequential block of bytes.
Either way, it's separate functions for each struct.
Instead, C should provide the general-purpose
functionality.

[Malcolm McLean]

Serialisation is fundamental operation that almost every program
needs to do.

But there are some issues. Endianness is trivial but irritating.
size_t varies in width, which means that fields which represent
counts of bytes don't have a natural size. Floating point conversion
cannot necessarily be done exactly from one compact binary format to
another. You can't serialise a pointer, of course.
Then whilst the serialiser knows what it is sending, the
deserialiser has to know what it is reading. So that creates an
asymmetry.
Often serialised data is wanted as text rather than binary. That
causes more problems, because you can get parse errors, you can
get numbers too large to fit in a type, you can have NaNs and
missing data, there aren't any universal conventions for delimiting
fields or escaping strings. Then you can have non-English characters.

Xml is a good convention, but it blows up data sizes. Also there are
some permitted xml constructs which mean that a parser is a hunk of
code. Then you need another parser to parse the output of the parser.

[Ian Collins]

Malcolm McLean wrote:
>>
> Serialisation is fundamental operation that almost every program
> needs to do.
>
> But there are some issues. Endianness is trivial but irritating.
> size_t varies in width, which means that fields which represent
> counts of bytes don't have a natural size. Floating point conversion
> cannot necessarily be done exactly from one compact binary format to
> another. You can't serialise a pointer, of course.
> Then whilst the serialiser knows what it is sending, the
> deserialiser has to know what it is reading. So that creates an
> asymmetry.
> Often serialised data is wanted as text rather than binary. That
> causes more problems, because you can get parse errors, you can
> get numbers too large to fit in a type, you can have NaNs and
> missing data, there aren't any universal conventions for delimiting
> fields or escaping strings. Then you can have non-English characters.
>
> Xml is a good convention, but it blows up data sizes. Also there are
> some permitted xml constructs which mean that a parser is a hunk of
> code. Then you need another parser to parse the output of the parser.

For serialisation JSON is more often than not a better candidate than
XML. It is less verbose and way easier to parse. For binary data,
there's BSON, which is even easier to parse. Both have well supported
libraries for just about every current programming language.

--
Ian Collins

[Les Cargill]

Ian Collins wrote:
> Malcolm McLean wrote:
>>>
>> Serialisation is fundamental operation that almost every program
>> needs to do.
>>
>> But there are some issues. Endianness is trivial but irritating.
>> size_t varies in width, which means that fields which represent
>> counts of bytes don't have a natural size. Floating point conversion
>> cannot necessarily be done exactly from one compact binary format to
>> another. You can't serialise a pointer, of course.
>> Then whilst the serialiser knows what it is sending, the
>> deserialiser has to know what it is reading. So that creates an
>> asymmetry.
>> Often serialised data is wanted as text rather than binary. That
>> causes more problems, because you can get parse errors, you can
>> get numbers too large to fit in a type, you can have NaNs and
>> missing data, there aren't any universal conventions for delimiting
>> fields or escaping strings. Then you can have non-English characters.
>>
>> Xml is a good convention, but it blows up data sizes. Also there are
>> some permitted xml constructs which mean that a parser is a hunk of
>> code. Then you need another parser to parse the output of the parser.
>
> For serialisation JSON is more often than not a better candidate than
> XML. It is less verbose and way easier to parse.

XML can be trivial if you don't use a lot of the language. ezXML isn't
half bad.

I think of the things we're serializing/deserializing in XML as indexed
by strings like: "domain.group.stuff.Thing.4.Leaf"

Of course, simply using "domain.group.stuff.Thing.4.Leaf = 42" is even
simpler...

> For binary data,
> there's BSON, which is even easier to parse. Both have well supported
> libraries for just about every current programming language.
>
--

Les Cargill

[glen herrmannsfeldt]

Malcolm McLean <malcolm...@btinternet.com> wrote:
> On Tuesday, November 11, 2014 2:09:45 AM UTC, JohnF wrote:

(snip)

>> Yeah, to me it seems like a major C shortcoming that
>> packed structs aren't reliably and portably available.
>> C, sometimes called a "portable assembly language",
>> is often used for the kind of low-level stuff that needs
>> this kind of feature. Instead, you typically have to
>> write each member of a struct individually, according
>> to its sizeof(member).

(snip)

> Serialisation is fundamental operation that almost every program
> needs to do.

That is what XDR was designed to do. It came from Sun along with
RPC, considering that one could use RPC between different
architectures.

http://www.ietf.org/rfc/rfc4506.txt

> But there are some issues. Endianness is trivial but irritating.
> size_t varies in width, which means that fields which represent
> counts of bytes don't have a natural size. Floating point conversion
> cannot necessarily be done exactly from one compact binary format to
> another. You can't serialise a pointer, of course.
> Then whilst the serialiser knows what it is sending, the
> deserialiser has to know what it is reading. So that creates an
> asymmetry.

XDR knows how big each item should be, and reads the appropriate
number of bytes.

> Often serialised data is wanted as text rather than binary. That
> causes more problems, because you can get parse errors, you can
> get numbers too large to fit in a type, you can have NaNs and
> missing data, there aren't any universal conventions for delimiting
> fields or escaping strings. Then you can have non-English characters.

> Xml is a good convention, but it blows up data sizes. Also there are
> some permitted xml constructs which mean that a parser is a hunk of
> code. Then you need another parser to parse the output of the parser.

Nice and portable, easy for people to read, but yes, big.

-- glen

[Ike Naar]

For 16-bit int, with INT_MIN=-65536 and INT_MAX=65535,
abs(word) has undefined behaviour for word=INT_MIN.

[Ike Naar]

On 2014-11-11, JohnF <jo...@please.see.sig.for.email.com> wrote:

It produces the same output for word=42 and for word=-42.
Is that intended?

[Alain Ketterlin]

Malcolm McLean <malcolm...@btinternet.com> writes:

> Xml is a good convention, but it blows up data sizes. Also there are
> some permitted xml constructs which mean that a parser is a hunk of
> code. Then you need another parser to parse the output of the parser.

I know I show my age, by I take the opportunity to mention XDR, which is
the marshalling/unmarshalling protocol used with RPC. Should be
available on all variants of Unix, and has been for decades. See RFC
4506 for details. There's even a portable version
(http://people.redhat.com/~rjones/portablexdr/)

But of course everybody is free to add layers of text formatting and
parsing. Be careful is you use floating point data, though.

-- Alain.

[Alain Ketterlin]

Ike Naar <i...@iceland.freeshell.org> writes:

> For 16-bit int, with INT_MIN=-65536 and INT_MAX=65535,
> abs(word) has undefined behaviour for word=INT_MIN.

You have two typos here: -65536 should be -32768, and 65535 32767.

-- Alain.

[David Brown]

On 11/11/14 02:33, JohnF wrote:
> David Brown <david...@hesbynett.no> wrote:
>> <<snip>> I don't think the world needs "RDC" or your
>> other languages - I don't think they are well designed,
>> and they do not fulfil any needs of developers.
>> The project is like someone building their own car -
>> for the builder, it is a labour of love that they enjoy
>> and learn from,
>
> Yes, precisely, I learned exactly the same lesson from
> my own "little language" www.forkosh.com/nutshell.html
> (and various other projects) that nobody but me has
> any use for. But I think you're being a bit too negative,
> or at least projecting a bit of a too-negative feeling.
> "Enjoy and learn from" should be your central theme here.
> You could develop your remarks into a really good essay
> about how to become a talented programmer. Programming
> to other people's specs doesn't do it alone.

I am all in favour of enjoying and learning - and I have tried to give
Rick helpful and constructive advice about RDC in posts here (some of it
as criticism - but hopefully /constructive/ criticism).

I think all programmers, at least experienced ones, have plans for their
"ideal" language in their heads. Very few ever get the time,
opportunity and skills needed to make it a reality. And very few of
these ever spread their language beyond their own office or bedroom.

I believe Rick will do better if he understands this. He has huge
ambitions - not just for his languages (he has several in the works),
but for his tools, editor, debugger, OS, library, and everything else he
can think of to replace just about every piece of software he can think
of. Ambitions and goals are good, even if they are always out of reach
- but making them /too/ high leads to frustration and disappointment.
So while I am always positive about someone trying to develop their
skills and write code that interests them, I would encourage him to be
realistic, and bring him back down to earth (or at least /one/ foot on
the ground). If I sounded cruel, it was to be kind.

[David Brown]

It is certainly possible to write code that reads or writes data in a
particular order, and works whether the target machine is big-endian or
little-endian. A very common method is to use a union of a byte array
and a 16-bit or 32-bit unsigned integer.

But when you want /efficient/ code, you want this all to boil down to a
single assembly instruction for "read 16-bit data" or "read 16-bit data
with byte swapping", depending on whether endianness matches or not.
And to do that, you want either compiler extensions, intrinsics,
builtins, etc., for the job, or at least you want compile-time or
preprocessor checking for endianness so that you can write more
efficient code.

[Malcolm McLean]

On Tuesday, November 11, 2014 8:29:27 AM UTC, David Brown wrote:
>
> It is certainly possible to write code that reads or writes data in a
> particular order, and works whether the target machine is big-endian or
> little-endian. A very common method is to use a union of a byte array
> and a 16-bit or 32-bit unsigned integer.
>
> But when you want /efficient/ code, you want this all to boil down to a
> single assembly instruction for "read 16-bit data" or "read 16-bit data
> with byte swapping", depending on whether endianness matches or not.
> And to do that, you want either compiler extensions, intrinsics,
> builtins, etc., for the job, or at least you want compile-time or
> preprocessor checking for endianness so that you can write more
> efficient code.
>

If constructing a 16-bit integer from two bytes is a bottleneck, then you're very
squeezed for resources indeed. Which I know is the case on some embedded
hardware.
Portable floating point writes are a different matter. It is irritating that 99%
of the time, it's either a write or a reverse followed by a write, but you've
got to break up and reconstruct the floating point number with logarithmic
time operations. However I've never found a problem on modern hosted
systems.

[David Brown]

On 11/11/14 11:14, Malcolm McLean wrote:
> On Tuesday, November 11, 2014 8:29:27 AM UTC, David Brown wrote:
>>
>> It is certainly possible to write code that reads or writes data in a
>> particular order, and works whether the target machine is big-endian or
>> little-endian. A very common method is to use a union of a byte array
>> and a 16-bit or 32-bit unsigned integer.
>>
>> But when you want /efficient/ code, you want this all to boil down to a
>> single assembly instruction for "read 16-bit data" or "read 16-bit data
>> with byte swapping", depending on whether endianness matches or not.
>> And to do that, you want either compiler extensions, intrinsics,
>> builtins, etc., for the job, or at least you want compile-time or
>> preprocessor checking for endianness so that you can write more
>> efficient code.
>>
> If constructing a 16-bit integer from two bytes is a bottleneck, then you're very
> squeezed for resources indeed. Which I know is the case on some embedded
> hardware.

I work with embedded systems - and yes, sometimes resources (cpu time
and code space in this case) are squeezed. Also, sometimes the tools
are not particularly good - I have worked with C compilers that would
take John's code with its "%256" and "/256" and call long, slow library
division code (decent compilers would typically generate byte
manipulation code).

But doing this sort of thing "manually" has three problems that I can see.

One is that it has a risk of errors - John's code, for example, has
several bugs as well as being overly complex.

Two is that it is likely to be sub-optimal - and even if you are using a
big, fast system, code like this turns up in low-level libraries, OS
filesystem drivers, and the like, where you want fast code. A brief
check of the linux kernel (since there is a convenient cross-reference
site) shows "le16_to_cpu" turning up in over 1000 files. You definitely
want the fastest code in these cases.

Third is that if you have a structure containing different sized items
in non-native endianness, it is tedious, ugly and error-prone to access
them. A compiler-supported pragma, attribute, or "named address space"
to handle this automatically would lead to clearer and faster code.

[JohnF]

David Brown <david...@hesbynett.no> wrote:
>
> One is that it has a risk of errors - John's code, for example, has
> several bugs as well as being overly complex.

What bugs, please?
(Forget the abs() stuff mentioned previously. That was just
a "sanity check". Shouldn't be called with a negative arg
to begin with.)
As for efficiency, I can certainly see your embedded point,
but not an issue that concerned me. For me, it's just at the end
of computations, to output results in required format.
So the total time it takes is linear in the number of bytes output.
Pretty inconsequential.
As for overly complex, please post a simpler one.
I was just trying to do the job in as simple-to-read-the-code way
as I could think of.

[Rick C. Hodgin]

David Brown wrote:
> I believe Rick will do better if he understands
> this. He has huge ambitions - not just for his
> languages (he has several in the works), but
> for his tools, editor, debugger, OS, library, and
> everything else he can think of to replace just
> about every piece of software he can think of.

http://www.libsf.org/indexmain.html

"LibSF was created to be a base for Christian,
God-fearing, Bible-believing, liberty software
advocates to contribute to the liberty software
world. It is our desire to have an alternative to
other non-faith-based foundations and projects
working on liberty software and open source
projects, one founded upon, and centered
around, Jesus, as the focus of our lives."

I also want to create a hardware stack which will
give us a full top-to-bottom machine founded
upon our offering unto the Lord.

See comp.arch, " Core proposal, i386 40-bit
dubbed "x40"" for my suggested core, but also
"For VIA Technologies former and current
employees / contractors" for my inquiry about
finding / using a hardware stack which is already
built atop faith in Jesus Christ.

Jesus is my foundation. What I am building I am
building for Him. You, David, and the other non-
believers, place no stock in such an effort or in
the purpose or intent in so doing because you
place no stock in Him. It does not bother you
(figurative you, the non-believer) to use Apple
products when Tim Cook comes out, or to buy
Starbucks coffee when they have LGBT adverts.

For those following Jesus Christ, it does sound
sirens of alarm, and we seek instead to follow
Him, to turn the crooked, twisted things of this
world being led by evil demonic forces into false
areas because of sin, back into the things which
are purposed upon God, and upon honoring
God.

In my doing this, you trash everything about me
personally, and everything I'm doing in my
projects. Such comes only from one source,
cold, hate-filled evil spirits speaking through
your mouth.

There are no rightly-founded efforts given over
to the Lord which are inappropriate. I am not
trying to blow up an abortion clinic, or kill those
who do not believe in Jesus Christ. I am saying
that all we should be doing, in all areas of our
lives, including computer use and programming,
should be founded upon Him, and a focused
and purposed effort upon Him, and in honoring
Him.

When the time is right, others will come to LibSF.
And all who come will do so from within, because
they ferl the same inner call to serve the Lord that
I feel.

Or not. It is entirely in the Lord's hands as to
whether or not LibSF succeeds. I am doing my
best on it, but I am one man working on the
evenings, weekends, and holidays. The project
needs a full-time effort, and more developers,
hence my continued offers in the various
forums I engage.

I love you, David. It's why I point you to Him, for
it is He Himself who loves you more.

[David Brown]

On 11/11/14 12:38, JohnF wrote:
> David Brown <david...@hesbynett.no> wrote:
>>
>> One is that it has a risk of errors - John's code, for example, has
>> several bugs as well as being overly complex.
>
> What bugs, please?
> (Forget the abs() stuff mentioned previously. That was just
> a "sanity check". Shouldn't be called with a negative arg
> to begin with.)

The "abs" was the main bug. But I believe the sign of the result of
division and modulo are implementation dependent for some C standards
(C11 makes the rounding always be towards zero - I haven't yet thought
through whether or not that helps).

> As for efficiency, I can certainly see your embedded point,
> but not an issue that concerned me. For me, it's just at the end
> of computations, to output results in required format.
> So the total time it takes is linear in the number of bytes output.
> Pretty inconsequential.
> As for overly complex, please post a simpler one.
> I was just trying to do the job in as simple-to-read-the-code way
> as I could think of.
>

I can think of two alternatives in C - using a union:

#include <stdint.h>

uint16_t swapUint16(uint16_t x) {
union {
uint16_t u16;
uint8_t u8s[2];
} a, b;
a.u16 = x;
b.u8s[0] = a.u8s[1];
b.u8s[1] = a.u8s[0];
return b.u16;
}


or using shifting:

#include <stdint.h>

uint16_t swapUint16(uint16_t x) {
return (x << 8) | (x >> 8);
}


Signed integer versions are done using automatic conversions:

int16_t swapInt16(int16_t x) {
return swapUint16(x);
}


You would normally make such functions "static inline" for efficiency.

Obviously my functions here don't have the same signature as your
example, since they are written to do the endian conversion only.

I leave it to the language lawyers to decide which, if either, of my two
functions is completely portable - and where they might fail. They will
certainly work on any two's complement system with 8-bit chars.

In reality - since I work on systems where efficiency is important
enough not to through it out of the window - I would usually have such
functions in a target-specific header using something like
__builtin_bswap16 or perhaps inline assembly if the compiler could not
generate optimal instructions. It is work that needs to be done once
for each new target I use - so very little effort in reality.

[David Brown]

On 11/11/14 13:05, Rick C. Hodgin wrote:
> David Brown wrote:
>> I believe Rick will do better if he understands
>> this. He has huge ambitions - not just for his
>> languages (he has several in the works), but
>> for his tools, editor, debugger, OS, library, and
>> everything else he can think of to replace just
>> about every piece of software he can think of.
>
> http://www.libsf.org/indexmain.html
>
> "LibSF was created to be a base for Christian,
> God-fearing, Bible-believing, liberty software
> advocates to contribute to the liberty software
> world. It is our desire to have an alternative to
> other non-faith-based foundations and projects
> working on liberty software and open source
> projects, one founded upon, and centered
> around, Jesus, as the focus of our lives."
>
> I also want to create a hardware stack which will
> give us a full top-to-bottom machine founded
> upon our offering unto the Lord.

As I said, your ambitions are well beyond what is realistic.

>
> See comp.arch, " Core proposal, i386 40-bit
> dubbed "x40"" for my suggested core, but also
> "For VIA Technologies former and current
> employees / contractors" for my inquiry about
> finding / using a hardware stack which is already
> built atop faith in Jesus Christ.
>
> Jesus is my foundation. What I am building I am
> building for Him. You, David, and the other non-
> believers, place no stock in such an effort or in
> the purpose or intent in so doing because you
> place no stock in Him. It does not bother you
> (figurative you, the non-believer) to use Apple
> products when Tim Cook comes out, or to buy
> Starbucks coffee when they have LGBT adverts.
>

Actually, I mostly avoid Apple products because they are a waste of
money - they are a triumph of style over substance, and I don't like the
style very much. I also think they are a prime example of capitalist
greed. But while I would not spend my money on a iPhone or a Mac, I
won't avoid something just because Apple is somewhat involved - thus I
am fine with cups for printing and clang as a compiler.

I avoid Starbucks because again it is a waste of money - it is far more
efficient in terms of money and the environment to get my coffee from
the coffee machine at the office, re-using the same cup. I also dislike
"big" corporations which push out small people, such as small cafés.
But I might buy the odd Starbucks coffee at an airport.

But these things are never black and white - every corporation or entity
of sufficient size has its good points and its bad points. For example,
Starbucks support for love and freedom in the face of outdated
prejudices is a strong point in its favour.

You make your choices here - supporting the causes you think are
important, and adding your little drop in the ocean in what you believe
to be the right place. It all adds up. I am a vegetarian - by avoiding
meat, a little less rainforest is cut down every year since a vegetarian
diet is more environmentally efficient. But I don't think I should
invent a whole new way of eating, with new supermarkets, new
restaurants, new recipe books just to fit /my/ choice of how to eat.
And I don't condemn other people as evil planet-burners for /their/
choice of diet, or try to convince them to change their ways.

> For those following Jesus Christ, it does sound
> sirens of alarm, and we seek instead to follow
> Him, to turn the crooked, twisted things of this
> world being led by evil demonic forces into false
> areas because of sin, back into the things which
> are purposed upon God, and upon honoring
> God.
>
> In my doing this, you trash everything about me
> personally, and everything I'm doing in my
> projects. Such comes only from one source,
> cold, hate-filled evil spirits speaking through
> your mouth.

No, the "hate" is in /your/ eyes and /your/ ears - you have convinced
yourself that you are surrounded by evil, and that everyone is against
you. It is pure paranoia - and at the risk of sounding like a cliché,
you should be talking to a specialist before it gets worse.

I am recommending that you put your efforts into work that interests
you, that benefits you, and that you learn from. And by all means make
it available to others - sharing is great, regardless of the reasons.
But I recommend you to be realistic in what you aim for - you cannot
change the world alone, and you will never be able to get anything like
the support your ideas demand.

>
> There are no rightly-founded efforts given over
> to the Lord which are inappropriate. I am not
> trying to blow up an abortion clinic, or kill those
> who do not believe in Jesus Christ. I am saying
> that all we should be doing, in all areas of our
> lives, including computer use and programming,
> should be founded upon Him, and a focused
> and purposed effort upon Him, and in honoring
> Him.

That's fine - whatever motivation a person has, it is a good thing to
use the skills and abilities he has. But /your/ skills and abilities
will not let you change the computing world as you want - they are not
sufficient for the scope of your ambition. Nor do they include
gathering a significant community of like-minded volunteers to help with
the work. It is simply /far/ too much for any person. I don't doubt
your dedication, and have no reason to doubt your programming skills -
but there is only one of you. Therefore I strongly encourage you to
pick a single task and try to do that well, rather than trying to do
everything and burning yourself out before getting anywhere at all.

[Phil Carmody]

Les Cargill <lcarg...@comcast.com> writes:

> Ian Collins wrote:
> > For serialisation JSON is more often than not a better candidate than
> > XML. It is less verbose and way easier to parse.
>
> XML can be trivial if you don't use a lot of the language.

Oh, pleeeeease. If you're not using both at the same time,
you're simply not using enough tech.

http://pic.dhe.ibm.com/infocenter/wsdatap/v6r0m0/topic/com.ibm.dp.xm.doc/json_jsonxconversionrules.html

Phil
--
The best part of re-inventing the wheel is that you get to pick how
many sides the new one has. -- egcagrac0 on SoylentNews

[Kenny McCormack]

In article <m3t292$vk9$1...@dont-email.me>,
David Brown <david...@hesbynett.no> wrote:
...

>Actually, I mostly avoid Apple products because they are a waste of
>money - they are a triumph of style over substance, and I don't like the
>style very much. I also think they are a prime example of capitalist
>greed. But while I would not spend my money on a iPhone or a Mac, I
>won't avoid something just because Apple is somewhat involved - thus I
>am fine with cups for printing and clang as a compiler.
>
>I avoid Starbucks because again it is a waste of money - it is far more
>efficient in terms of money and the environment to get my coffee from
>the coffee machine at the office, re-using the same cup.

Well, it certainly sounds to me like you & Rick are on the same page.
Your reasons/motivations for disliking these two fine, upstanding, American
corporations may differ, but your actions are the same - and it is actions,
not reasons, that ultimately matter.

Both look equally irrational to this outside observer, but I'm sure each
makes sense to each of you. You certainly seem like birds of a feather to
me.

--
The book "1984" used to be a cautionary tale;
Now it is a "how-to" manual.

[Malcolm McLean]

On Tuesday, November 11, 2014 10:40:19 AM UTC, David Brown wrote:
>
> Two is that it is likely to be sub-optimal - and even if you are using a
> big, fast system, code like this turns up in low-level libraries, OS
> filesystem drivers, and the like, where you want fast code. A brief
> check of the linux kernel (since there is a convenient cross-reference
> site) shows "le16_to_cpu" turning up in over 1000 files. You definitely
> want the fastest code in these cases.
>

Typically deserialisation is rather slow. Often you're accessing physical hardware
which is so slow that almost any software operation isn't going to make a whole
lot of difference. Then quite commonly it's necessary to allocate memory for
strings or other variable-length fields. There's also often a compressor which
requires bit-resolution access, which very few processors will do efficiently.

There can be cases where you need a blindingly fast solution, of course, but
they're the exception.

[JohnF]

David Brown <david...@hesbynett.no> wrote:
> On 11/11/14 12:38, JohnF wrote:
>> David Brown <david...@hesbynett.no> wrote:
>>>
>>> One is that it has a risk of errors - John's code, for example, has
>>> several bugs as well as being overly complex.
>>
>> What bugs, please?
>> (Forget the abs() stuff mentioned previously. That was just
>> a "sanity check". Shouldn't be called with a negative arg
>> to begin with.)
>
> The "abs" was the main bug.

Good. No problem, then.

> But I believe the sign of the result of
> division and modulo are implementation dependent for some C standards
> (C11 makes the rounding always be towards zero - I haven't yet thought
> through whether or not that helps).

Don't understand. We're talking integer arithmetic.

>> As for efficiency, I can certainly see your embedded point,
>> but not an issue that concerned me. For me, it's just at the end
>> of computations, to output results in required format.
>> So the total time it takes is linear in the number of bytes output.
>> Pretty inconsequential.
>> As for overly complex, please post a simpler one.
>> I was just trying to do the job in as simple-to-read-the-code way
>> as I could think of.

I think your functions below are just swapping.
My function doesn't swap. It >>maybe<< swaps.
If the arcitecture is little-endian to begin with, it doesn't swap.
If big-endian, it swaps. And that happens "automatically".
Suppose you have the number int i = (63) + 256*(127); that you want to
write little-endian. But you don't where the (63) byte is or where the
(127) byte is. My function gets them in the proper order regardless
of where they are. It doesn't care where they are.
That's because i%256=63 and (i/256)%256=127 regardless of
where the bytes are. The cpu has to deal with endianness
so that arithmetic works right.

[Rick C. Hodgin]

On Tuesday, November 11, 2014 8:17:45 AM UTC-5, David Brown wrote:
> As I said, your ambitions are well beyond what is realistic.

Believers do not operate alone in this world. It is our service unto
the Lord, but it is Him working all things out according to His will and
His purposes.

Should there be any part of His plans for me or others to work with LibSF,
then it will come to pass and cannot fail. If there be no part of His plans
for me or others to work with LibSF, then He will sort it out and move me
along to the thing(s) I should be doing.

I do not stand alone. Nor am I alone. I offer my best unto Him from the
place of having a true and purposed heart unto Him. And it is He who sees
through the outward facades, and into the inner-most man, the true intents
we pursue, and it is He who will move me along to other place(s) if that's
what's needed. And if not, then He will bring others to work on this
project and it will succeed.

It is His will acting in our lives as we purpose upon Him.

There's a good movie you should watch regarding this. It's called Flywheel.
It's about a used car salesman who is dishonest, but God reveals to him by
opening his eyes about his dishonest ways and how they are harming people.
He has a change of heart, gives his business over to the Lord, does things
honestly and truly, and is about ready to go under. But God works a miracle
in his life and he sees the fruit of his faith in the Lord directly before
his eyes.

It is not always like this for believers financially, but it is always like
that for believers spiritually. We see Him moving in our lives to bring
those around us to Him, those who have an ear to hear, and those to whom He
has eternal purposes because they will hear Him, come out, and be saved.

Our offerings unto the Lord are of the right course. It is what He asks us
to do. These pursuits and offerings are right, true, and proper. He teaches
us this in scripture:

http://biblehub.com/proverbs/3-6.htm
"In all thy ways acknowledge him, and he shall direct thy paths."

http://biblehub.com/proverbs/16-3.htm
"Commit thy works unto the LORD, and thy thoughts shall be established."

http://biblehub.com/psalms/37-5.htm
"Commit thy way unto the LORD; trust also in him; and he shall bring it
to pass."

http://biblehub.com/colossians/3-17.htm
"And whatsoever ye do in word or deed, do all in the name of the Lord
Jesus, giving thanks to God and the Father by him."

And he also gives a warning about all men, those who are not purposed
singularly upon Jesus Christ:

http://biblehub.com/philippians/2-21.htm
"For all seek their own, not the things which are Jesus Christ's."

-----
There is wisdom in scripture as to our true and focused hope and purpose
upon this Earth. God has plans for us, and He reveals those plans to us.
It is only because of the unseen-with-our-eyes enemies operating against
us, through us, through our sinful, fallen flesh state, which has men tied
up in bondage seeking after self-satiating lusts only, doing only harm one
to another, that we are drawn away from God's plans and purposes in our
lives, for not one of His plans are hidden, nor burdensome. They are
simply focused upon the Lord God Almighty, and not upon self, which is why
so many in this world absolutely reject them, reject Him, because there is
no desire to pursue what is right and true as per His guidance, but rather
it is only what the individual wants to pursue with their limited view on
things, their short lifespan, their inability to work things out for the
benefit of all, which means they are only satisfying self, and are only
self-seeking.

It is the nature of the battle all men face, and the enemy plays upon
each man's own personal desires and lusts to tempt him toward those things
he wants that person to do. And all will do as the enemy wants, except
for those who are willing to hear the truth, to come out from that great
deception, and focus their lives unto the One who has real purpose, who
is Himself the only source of Truth, and the One who holds every key to
every door, both here upon the Earth, and in eternity.

Men pass up eternity because the enemy blinds them to His eternal Kingdom.
They focus upon what they can see, hear, taste, touch, and smell, those
things the physical/natural world gives us only. They are spiritually
dead and therefore know in their core-most self that there is nothing
beyond that which they know, or believe man can know on his own. They
will not hear the truth so it is forever hidden from them. And they fill
their lives with trivial pursuits, the lot of which are distractions away
from our true purpose on this Earth, which is to serve Him in all we do,
allowing Him to establish our ways and paths.

I urge everyone reading this to come out from that deception and seek
from Him and Him alone, seek His counsel on how the course and path of
your life should go. Ask Him to reveal it to you, and to put you on it,
and to take away your sin, and to purpose you upon His goals which are
eternal goals. Ask Him to save you, and to guide you in everything, to
be your God, as you will be His people.

You will be forever glad you did.

[David Brown]

On 11/11/14 14:58, Kenny McCormack wrote:
> In article <m3t292$vk9$1...@dont-email.me>,
> David Brown <david...@hesbynett.no> wrote:
> ...
>> Actually, I mostly avoid Apple products because they are a waste of
>> money - they are a triumph of style over substance, and I don't like the
>> style very much. I also think they are a prime example of capitalist
>> greed. But while I would not spend my money on a iPhone or a Mac, I
>> won't avoid something just because Apple is somewhat involved - thus I
>> am fine with cups for printing and clang as a compiler.
>>
>> I avoid Starbucks because again it is a waste of money - it is far more
>> efficient in terms of money and the environment to get my coffee from
>> the coffee machine at the office, re-using the same cup.
>
> Well, it certainly sounds to me like you & Rick are on the same page.
> Your reasons/motivations for disliking these two fine, upstanding, American
> corporations may differ, but your actions are the same - and it is actions,
> not reasons, that ultimately matter.

Opinions on what make "fine, upstanding" corporations vary enormously.
I am not an American - remember that a company that is spreading /your/
way of life and /your/ culture to other countries, and bringing back
money to /your/ country, is exactly the opposite when viewed from the
outside.

And some people see free market competition and capitalism as being
about freedom and the right to earn from your own hard work, others see
there is a risk of greed and exploitation if there are not strong limits
in place. There is room for all opinions and thoughts here (at least
for those of us living in free countries).

(I don't want to debate politics or economics here - I am merely stating
that everyone has a right to their opinions, and there is no monopoly on
imagined "correct" answers.)

>
> Both look equally irrational to this outside observer, but I'm sure each
> makes sense to each of you. You certainly seem like birds of a feather to
> me.
>

The whole point - which seems to have passed you by - is that people
have the right to choose what /they/ think is important, what /they/
think are good moral or ethical choices, and where /they/ want to strike
a balance between ideals and practicalities. I object to Rick's
labelling me as a hateful person guided by evil, just because I do not
share his beliefs - thus a gave a few examples of how I make choices
guided by something other than personal gain. And I specifically do not
judge or condemn people who make different choices - that is the key
difference between Rick and myself (and almost everyone else - we /all/
have opinions, beliefs, or habits that appear irrational to others).

[Rick C. Hodgin]

On Tuesday, November 11, 2014 9:50:28 AM UTC-5, David Brown wrote:
> I object to Rick's labelling me as a hateful person guided by evil,
> just because I do not share his beliefs

The Bible is the source of these assessments, David. Not me. I convey
what the Lord teaches us in scripture about our state. And His words
are true, and are evident by direct observation:

http://biblehub.com/matthew/12-30.htm
"He that is not with me is against me; and he that gathereth not with
me scattereth abroad."

Jesus is truth. By definition if someone is not with Him, they are
against Him, meaning they are not with truth, but are against truth.
He who is Life operates in life-giving ways. He who is against life
operates only in life-harming / life-ending ways.

Satan is the enemy of God and he is also our enemy. There is God's
voice which speaks Life, and there is his voice (Satan's voice) which
speaks death. We are also told and warned about the power of this
enemy which is against us, which is why we need Jesus Christ (because
the enemy HAS our number through our sinful, fallen flesh, and it is
only by turning away from our lusts, and pursuing God in Spirit and in
Truth that we are set free from that bondage):

http://biblehub.com/revelation/12-9.htm
"And the great dragon was cast out, that old serpent, called the Devil,
and Satan, which deceiveth the whole world: he was cast out into the
earth, and his angels were cast out with him."

"Deceiveth the whole world..."

All men face a battle they cannot win, and have already lost. There
is only one way out, and that is through the One who can make a way
out of no way, who is God Almighty, who came here to pay the price of
our sin for us, and who is able to save to the uttermost all those
who will come to Him, humble themselves, repent, and ask forgiveness.
He is mighty to forgive, mighty to save, mighty to lead into eternal
life.

I can only correct your misguided thoughts and beliefs, David, as per
the teachings of the One who is God Almighty. I can only teach you
where the enemy has espoused falseness, and where the Lord rebukes him
and us in our wayward thinking, our wayward ways. I cannot make you
believe or do anything toward Him or His ends.

I am able to pray for you, and I have, and will (Lord willing), that
He may open your eyes, and save you too. I carry that same prayer
for the others in this group as well.

[David Brown]

On 11/11/14 15:29, JohnF wrote:
> David Brown <david...@hesbynett.no> wrote:
>> On 11/11/14 12:38, JohnF wrote:
>>> David Brown <david...@hesbynett.no> wrote:
>>>>
>>>> One is that it has a risk of errors - John's code, for example, has
>>>> several bugs as well as being overly complex.
>>>
>>> What bugs, please?
>>> (Forget the abs() stuff mentioned previously. That was just
>>> a "sanity check". Shouldn't be called with a negative arg
>>> to begin with.)
>>
>> The "abs" was the main bug.
> Good. No problem, then.
>
>> But I believe the sign of the result of
>> division and modulo are implementation dependent for some C standards
>> (C11 makes the rounding always be towards zero - I haven't yet thought
>> through whether or not that helps).
>
> Don't understand. We're talking integer arithmetic.
>

If "word" is -1023, is "word % 256" equal to -255 (with "word / 256"
equal to -3), or is it 1 (with the division equal to -4) ? As far as I
can understand the standards, they are equally valid until C11 (which
dictates the -255,-3 version).

Using abs(), you side-stepped this issue somewhat since your numerator
is never negative (except for -32767), but if abs is removed then the
issue appears.

>>> As for efficiency, I can certainly see your embedded point,
>>> but not an issue that concerned me. For me, it's just at the end
>>> of computations, to output results in required format.
>>> So the total time it takes is linear in the number of bytes output.
>>> Pretty inconsequential.
>>> As for overly complex, please post a simpler one.
>>> I was just trying to do the job in as simple-to-read-the-code way
>>> as I could think of.
>
> I think your functions below are just swapping.
> My function doesn't swap. It >>maybe<< swaps.
> If the arcitecture is little-endian to begin with, it doesn't swap.

Sorry - I think I missed the point here somewhere. Yes, my functions
always swap. When I use such functions, it is with compile-time
knowledge (such as target-dependent headers, or compiler pre-processor
symbols) as to when swaps are needed - for efficient code, it is
important to swap when you have to, and to let the compiler generate
normal multi-byte loads and stores when they are valid.

Let me try again here:

extern void putByte(uint8_t);
void putLE16(uint16_t x) {
putByte(x);
putByte(x >> 8);
}

I suppose if I were to fit it into the signature you have, it would be:

int putblkword(BYTE *blk, int offset, int word) {
BYTE thisword[2];
unsigned int x = word;

thisword[0] = x;
thisword[1] = (x >> 8);
return putblkbytes(blk, offset, thisword, 2);
}


From long experience of shifting and re-arranging bits and bytes, I have
no doubts that it is often easier, clearer, safer and/or more efficient
to use unsigned types.

The code may have issues on targets that are not two's complement - but
quite frankly, I don't care, and nor do almost any other programmers,
since such targets are virtually non-existent. The code also depends on
the target having 8-bit chars, which is more relevant as there are a few
modern, useful processors that don't support 8-bit chars. But code for
such systems usually has to be specially written anyway.

[David Brown]

Even assuming you are right (and I'm far from convinced that you /are/
right, but that would be another topic), why would you want to go out of
your way to make slow code even slower? If you have to wait 100 ms to
read in your blocks of data, why would you want to spend 2 ms converting
endianness when you could do it in 1 ms? In this particular case,
making a good, efficient endian swap is easier and clearer than making a
bad one - and with a target-specific header or preprocessing compiler
symbols such as "__BYTE_ORDER__" you can get near-optimal code for
endian translation. With an OS or low-level libraries, you can add a
line of inline assembly to a header to get completely optimal code.

Maybe the use of a good endian swap function only means 1% difference in
time compared to a bad one - but these sorts of things add up.
Remember, it is not /optimisation/ that is the root of all evil, only
/premature/ optimisation.

[David Brown]

On 11/11/14 16:09, Rick C. Hodgin wrote:
> On Tuesday, November 11, 2014 9:50:28 AM UTC-5, David Brown wrote:
>> I object to Rick's labelling me as a hateful person guided by evil,
>> just because I do not share his beliefs
>
> The Bible is the source of these assessments, David. Not me. I convey
> what the Lord teaches us in scripture about our state. And His words
> are true, and are evident by direct observation:
>

Quotations from the Bible are not evidence of any truth in the Bible -
that is merely a circular argument ("I'm right because I say I am").

Accept some responsibility for yourself. /You/ label others as evil.
/You/ choose to read and interpret the Bible in the way you do, and
/you/ choose to believe that your interpretation is some sort of
absolute truth. And /you/ choose to go against that book in how you
judge others.

Choose whatever beliefs you are happy with. But don't try to force your
chosen beliefs on others, or judge them by your own opinions.

[Richard Heathfield]

Rick C. Hodgin wrote:

> On Tuesday, November 11, 2014 9:50:28 AM UTC-5, David Brown wrote:
>> I object to Rick's labelling me as a hateful person guided by evil,
>> just because I do not share his beliefs
>
> The Bible is the source of these assessments, David.

No, it isn't. The Bible teaches that the fruit of the Spirit is love, joy,
peace, patience, kindness, goodness, faithfulness, gentleness, and self-
control. You don't love people by calling them hate-filled. You don't spread
the message of joy by banging on about evil spirits. You don't engender
peace by posting inflammatory material on Usenet (which, like it or not, is
what you are doing). Rick, people in this newsgroup only know you by your
fruit. And that fruit is almost wholly bitter in its character and nature,
despite your occasional attempts to season it.

It would be better if you didn't post Christian polemic in comp.lang.c but,
if you must, for heaven's sake make it /accurate/ Christian polemic.

And please, please, please remember that "disagreeing with Rick" does not
mean the same thing as "is a hate-filled child of the devil". I refer you to
Matthew 7:1.

> Not me. I convey
> what the Lord teaches us in scripture about our state. And His words
> are true, and are evident by direct observation:
>
> http://biblehub.com/matthew/12-30.htm
> "He that is not with me is against me; and he that gathereth not with
> me scattereth abroad."

Mark 9:40 - "Whoever is not against us is for us."

A hostile stance such as the one you take is more likely to turn people away
from God than it is to turn them towards Him. That may not be your intent,
but it is certainly the most likely outcome. It is counter-productive.

>
> Jesus is truth. By definition if someone is not with Him, they are
> against Him, meaning they are not with truth, but are against truth.

By Jesus's definition, if someone is not against Him, they are for Him. If
someone is not against Truth, they are for Truth.

A few weeks ago, you posted a lie about a supposed discovery of an eye-
witness account of a miracle or something of the kind. Does that mean you
are against Truth? No, of course not. It just means you're crap at research.
There are some people in this newsgroup who are much better than you at
research. They are, therefore, more skilled at unearthing truth than you
are. Using your yardstick, that means they're closer to Jesus than you are.

You're trying to use reason to justify your position, but you would do
better to use reason to /deduce/ your position. Don't make the mistake of
attacking reason. To do so is bad theology.

> He who is Life operates in life-giving ways. He who is against life
> operates only in life-harming / life-ending ways.

He who wishes to persuade people of the truth of his position would do well
not to start out by calling them hate-filled.

<snip>

> I can only correct your misguided thoughts and beliefs, David, as per
> the teachings of the One who is God Almighty.

As far as I can make out, David hasn't espoused any misguided thoughts or
beliefs. Of course, he may have done so, and I've simply forgotten. Perhaps
you could point out some examples to back up your position?

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[Ben Bacarisse]

Richard Heathfield <inv...@see.sig.invalid> writes:
<snip>

> It would be better if you didn't post Christian polemic in comp.lang.c

but...

> Rick C. Hodgin wrote:
<snip>
>> I can only correct your misguided thoughts and beliefs, David, as per
>> the teachings of the One who is God Almighty.
>
> As far as I can make out, David hasn't espoused any misguided thoughts or
> beliefs. Of course, he may have done so, and I've simply forgotten. Perhaps
> you could point out some examples to back up your position?

... you ask for some more?

--
Ben.

[Kenny McCormack]

In article <m3tar0$418$1...@dont-email.me>,

David Brown <david...@hesbynett.no> wrote:
>On 11/11/14 16:09, Rick C. Hodgin wrote:
>> On Tuesday, November 11, 2014 9:50:28 AM UTC-5, David Brown wrote:
>>> I object to Rick's labelling me as a hateful person guided by evil,
>>> just because I do not share his beliefs
>>
>> The Bible is the source of these assessments, David. Not me. I convey
>> what the Lord teaches us in scripture about our state. And His words
>> are true, and are evident by direct observation:
>>
>
>Quotations from the Bible are not evidence of any truth in the Bible -
>that is merely a circular argument ("I'm right because I say I am").

You'd be amazed at how many Bible thumpers have absolutely no problem with
the argument that the Bible must be infallible; it says so right there in
the Bible.

In fact, all organized religion boils down to that - the organization tells
you that it is infallible. That infallibility is an integral part of the
dogma of the org.

The same can be said of the C Standard (getting back on topic...)
The C standard tells us that it is the be-all, end-all, and last word on
what is C.

--
A liberal, a moderate, and a conservative walk into a bar...

Bartender says, "Hi, Mitt!"

[Rick C. Hodgin]

On Tuesday, November 11, 2014 10:48:18 AM UTC-5, Richard Heathfield wrote:

> Rick C. Hodgin wrote:
> > The Bible is the source of these assessments, David.
>
> No, it isn't. The Bible teaches that the fruit of the Spirit is love, joy,
> peace, patience, kindness, goodness, faithfulness, gentleness, and self-
> control. You don't love people by calling them hate-filled.

I didn't say David was hate-filled. I said that there are cold, hate-
filled evil spirits speaking through him.

Here is my quote:

"In my doing this, you trash everything about
me personally, and everything I'm doing in my
projects. Such comes only from one source,
cold, hate-filled evil spirits speaking through
your mouth."

It is the evil spirits, Satan and all his demon imps, who are the enemy.
It is man in his fallen sinful state that is the slave of those demon
imps because man cannot know the truth from the lie because of sin, and
the fallen state.

It is the Spirit of Truth, Jesus Christ, who corrects and rebukes all
falseness. It is Jesus Christ who guides men toward rightness. And it
is the evil spirits operating in men that keep men from coming to Jesus
Christ, which find all manner of explanation as to why He should not be
listened to or sought after. And it is those same evil spirits who fill
men's heads with goals of trivial pursuits and non-importance.

To be absolutely clear about this: It is entirely a spiritual battle
that all men face. We are ALL on the losing end of that battle because
we are fallen, in sin, all of us It is only Jesus Christ, and His
atoning sacrifice on the cross, which gives men any hope of redemption,
of salvation, of being set free from those chains of sinful bondage
which only leads men to the bowels of Hell.

Jesus alone is Truth. And it is to Him I point each of you. It is
to Him I espouse, and it is unto Him that I put forth all of my efforts
so they will not be built alongside sinful, fallen men's pursuits, but
rather built upon an offering of love unto Jesus Christ.

I seek to build a cadre, a full repertoire of software in all manner
of men's needs, built atop that love offering from within that comes
from men seeking after Jesus Christ truly and purposefully in their
lives.

I have these applications already planned out, but there are also
more than this:

http://www.libsf.org/software

A new operating system, called Exodus, based on x86. To accomplish
this I am completing my current compiler project and debugger. Next,
a port of Exodus to ARM, called Armodus. Then to come back to Exodus
and make a 64-bit version. And then back to ARM and mark a 64-bit
version.

I also desire to make the x40-based CPU I mentioned in comp.arch. If
that were the case, I might forego the entire Exodus project and head
in that direction, so that the hardware we have is built atop this
foundation of an offering unto Him.

It may be that He has something else for me, however, but all of these
efforts stem from the internal drive and desire to offer up everything
I have unto Him, and for Him, by name, purposefully, unto others in
this world that they might see that offering, see value in it, and come
to Him as well.

There is a battle taking place in this world. It is between the enemy
of God and each of us, as God has already defeated the enemy. The only
places where the battle is being fought today is within the hearts, and
minds of each one of us ... will we hear and pursue God and His Holy
Spirit, will we see the value in His Son's atoning death and sacrifice
at the cross, or will we reject all of it.

One choice leads to eternal life. One leads to eternal death. And there
is a cunning, cunning enemy at work against you who will totally own you
and lead you to your destruction if you'll let him. But there is a MUCH
more powerful God ready and willing to draw you to Him and save you out
from this death sentence should you show even the smallest inking of the
tiniest ebb of a desire to hear Him, hear His truth, to come out and be
saved.

It's the story of the Prodigal Son, who, upon coming to his senses,
turning away from his sore state, and heading back to where he should've
been (and even he heading back with false intentions/motives, not to be
a son again, but only a hired hand), his father met him while he was still
a long way away, afar off, and was so glad that he had returned that he
killed the fatted calf and through a huge banquet for him.

It is the same for every one of us who repents. Even though we've all
done the most despicable things in the sight of a Holy, Holy, Holy God,
yet is He most pleased to receive us when we will humble ourselves,
repent, and turn toward Him.

He is God Almighty and would be justified in sending every last one of
us to Hell forever, for all of us are wicked to the core. But it is His
will, His offering, His love, that draws us out of that fate, and it is
then His Holy Spirit operating in us which causes us to change from the
inside out, to be a changed being, so that we are then pursuing and
purposing our lives upon Him and His goals, because they are now again
our goals as we are alive again in eternity.

Jesus is the way. The enemy tries to keep every one of us from Jesus.
He does this because he knows that Jesus has the power, authority, will,
and desire to save, and that He will save all who come to Him.

Don't be fooled by an enemy whose entire empire is defeated, whose entire
empire is built upon rebellion and lies. Seek the truth, and let the
truth rule and reign in your heart. Be set free from the bondage by the
One who has conquered death, Hell, and the grave.

Jesus is that One. He is Power, and He is Love, and He is rightness and
trueness. There is none other, and it is only to Him that I point each
of you.

[Rick C. Hodgin]

On Tuesday, November 11, 2014 11:08:48 AM UTC-5, Rick C. Hodgin wrote:
> I have these applications already planned out, but there are also
> more than this:
> http://www.libsf.org/software

Should be:

http://www.libsf.org/projects

[James Kuyper]

On 11/11/2014 10:18 AM, David Brown wrote:
> On 11/11/14 15:29, JohnF wrote:
>> David Brown <david...@hesbynett.no> wrote:
>>> On 11/11/14 12:38, JohnF wrote:

...

>>> But I believe the sign of the result of
>>> division and modulo are implementation dependent for some C standards
>>> (C11 makes the rounding always be towards zero - I haven't yet thought
>>> through whether or not that helps).
>>
>> Don't understand. We're talking integer arithmetic.
>>
>
> If "word" is -1023, is "word % 256" equal to -255 (with "word / 256"
> equal to -3), or is it 1 (with the division equal to -4) ? As far as I
> can understand the standards, they are equally valid until C11 (which
> dictates the -255,-3 version).

You are correct about what used to be allowed, and about what it now
required, but you have the transition date incorrect. That change was
made in C99.

[Richard Heathfield]

No, just *some*. Or even one, to be going on with.

[glen herrmannsfeldt]

David Brown <david...@hesbynett.no> wrote:

(snip)

> If "word" is -1023, is "word % 256" equal to -255 (with "word / 256"
> equal to -3), or is it 1 (with the division equal to -4) ? As far as I
> can understand the standards, they are equally valid until C11 (which
> dictates the -255,-3 version).

Fortran requires the C11 form, and has for a long time.

That makes it less likely that any hardware would support a different
form, which is pretty much what happened.

> Using abs(), you side-stepped this issue somewhat since your numerator
> is never negative (except for -32767), but if abs is removed then the
> issue appears.

-- glen

[James Kuyper]

On 11/11/2014 09:29 AM, JohnF wrote:
> David Brown <david...@hesbynett.no> wrote:

...

>> But I believe the sign of the result of
>> division and modulo are implementation dependent for some C standards
>> (C11 makes the rounding always be towards zero - I haven't yet thought
>> through whether or not that helps).
>
> Don't understand. We're talking integer arithmetic.

What feature of the above paragraph leaves you confused about that
issue? The operands of the modulus operator are required to have integer
types, and division is permitted on any arithmetic type (6.5.5p2). All
integer types are arithmetic types (6.2.5p18). The defined behavior of
integer division involves rounding (6.5.5p6), and that definition was
changed in C99 (not C2011) to mandate rounding toward 0.

[Richard Heathfield]

Rick C. Hodgin wrote:

> On Tuesday, November 11, 2014 10:48:18 AM UTC-5, Richard Heathfield wrote:
>> Rick C. Hodgin wrote:
>> > The Bible is the source of these assessments, David.
>>
>> No, it isn't. The Bible teaches that the fruit of the Spirit is love,
>> joy, peace, patience, kindness, goodness, faithfulness, gentleness, and
>> self- control. You don't love people by calling them hate-filled.
>
> I didn't say David was hate-filled. I said that there are cold, hate-
> filled evil spirits speaking through him.

I accept the (trivial) correction, but you're wrong about the evil spirits,
too.

I also note that you choose not to engage in the discussion any further than
that. Presumably you agree with the following points:

1) your polemic is inaccurate;
2) disagreeing with you is not the same thing as being filled with evil
spirits;
3) your polemic is counter-productive;
4) others here are closer to Truth than you are in at least some respects;
5) it is better to use reason to deduce the truth than to justify opinion;
6) David hasn't espoused any misguided thoughts or beliefs.

Of course, you could just ignore the whole thing and carry on posting Bible
quotes and wildly inaccurate interpretations thereof. Alas, this is what I
am coming to expect.

[Ike Naar]

On 2014-11-11, Alain Ketterlin <al...@dpt-info.u-strasbg.fr> wrote:
> Ike Naar <i...@iceland.freeshell.org> writes:
>
>> For 16-bit int, with INT_MIN=-65536 and INT_MAX=65535,
>> abs(word) has undefined behaviour for word=INT_MIN.

You're absolutely right. Good catch.

[David Brown]

On 11/11/14 17:04, Kenny McCormack wrote:
> In article <m3tar0$418$1...@dont-email.me>,
> David Brown <david...@hesbynett.no> wrote:
>> On 11/11/14 16:09, Rick C. Hodgin wrote:
>>> On Tuesday, November 11, 2014 9:50:28 AM UTC-5, David Brown wrote:
>>>> I object to Rick's labelling me as a hateful person guided by evil,
>>>> just because I do not share his beliefs
>>>
>>> The Bible is the source of these assessments, David. Not me. I convey
>>> what the Lord teaches us in scripture about our state. And His words
>>> are true, and are evident by direct observation:
>>>
>>
>> Quotations from the Bible are not evidence of any truth in the Bible -
>> that is merely a circular argument ("I'm right because I say I am").
>
> You'd be amazed at how many Bible thumpers have absolutely no problem with
> the argument that the Bible must be infallible; it says so right there in
> the Bible.

At least it's self-consistent!

Many religious people add some sort of personal justification (such as
"I know it doesn't make sense, and I can't explain it, but I know in my
heart that it is true"). I can appreciate that - it is not unlike being
in love in being absolutely irrational, and yet absolutely true in a
very subjective sense.

What amazes me sometimes is how some religious people think arguments
like this are /rational/. I am happy for people to believe what they
want - and it is an important human right to have a freedom of belief
(though not necessarily freedom to act on those beliefs, of course).
And I am happy to hear that people are happy and content with their
beliefs (or lack thereof). I think it is also fine to discuss these
things in the right context - or occasionally, in the wrong context.

But I am not keen on a "holier than thou" attitude, or condescending and
disrespectful "I'll pray for you" comments. And I don't like being
called "evil", "hateful", or "possessed by Satan". I may occasionally
have done evil things - I am no more perfect than the next person - but
regardless of religion one should always strive to judge the sin, not
the sinner.

People can have their beliefs (or lack thereof), and I'll have mine (or
lack thereof).

>
> In fact, all organized religion boils down to that - the organization tells
> you that it is infallible. That infallibility is an integral part of the
> dogma of the org.

Yes, that is common to all religions as far as I know. That is why,
contrary to some people's arguments, "science" or "belief in science" is
not a religion, as science always aims to find flaws in existing theory.

>
> The same can be said of the C Standard (getting back on topic...)
> The C standard tells us that it is the be-all, end-all, and last word on
> what is C.
>

And like other holy books, it conflicts with the real world, where
compilers never quite match the standards.