On Wednesday, December 8, 2021 at 3:16:25 PM UTC-5, Keith Thompson wrote:

> > In case anyone wants to look at: TEST.C
> > This file is ENCTXTed to protect from online reformatting.
> > To Decode get: Daves Old Computers->Personal->Downloads->ENCTXT
>> ...
> I don't think many people are going to download EXCTXT so they can
> decode your source file.
>
> You can just include code inline in a post. As long as the lines aren't
> too long it shouldn't be a problem.

Unfortunately, I only have access to newsgroups now through "google groups" which horrendously
re-formats any text I post... C source I've tried to post "inline" always comes out horrible:
Spacing removed, lines joined etc.

ENCTXT is an easy way to get the original text, doesn't have to be "installed" etc, I include a DVM binary
(which can work on Win or Linux "as is") but also the full C source code which I have confirmed compiles
(and works correctly) with Micro-C, LCC and GCC (and probably lots of other compilers) so you can see
exactly how it works and what it does... and compile it yourself "to be sure".

And it's only needed if you actually want to look at code I've posted!

Regards,
Dave

Dave Dunfield <dave.dunfield@gmail.com> writes:

> On Wednesday, December 8, 2021 at 3:16:25 PM UTC-5, Keith Thompson wrote:
>
>>> In case anyone wants to look at: TEST.C
>>> This file is ENCTXTed to protect from online reformatting.
>>> To Decode get: Daves Old Computers->Personal->Downloads->ENCTXT
>>> ...
>>
>> I don't think many people are going to download EXCTXT so they can
>> decode your source file.
>>
>> You can just include code inline in a post. As long as the lines aren't
>> too long it shouldn't be a problem.
>
> Unfortunately, I only have access to newsgroups now through "google
> groups" which horrendously re-formats any text I post... C source
> I've tried to post "inline" always comes out horrible: Spacing
> removed, lines joined etc.
>
> ENCTXT is an easy way to get the original text, doesn't have to be
> "installed" etc, I include a DVM binary (which can work on Win or
> Linux "as is") but also the full C source code which I have
> confirmed compiles (and works correctly) with Micro-C, LCC and GCC
> (and probably lots of other compilers) so you can see exactly how it
> works and what it does... and compile it yourself "to be sure".

Please either post the code directly or post it in base64. The
cryptic directions for how to get ENCTXT are, at least for me,
completely useless. Or if you want post the .c code for ENCTXT,
and let other people worry about taking care of google groups
formatting screwups.

(Incidentally, can you explain why you can't set up a news
account with one of several few news providers, such as
eternal-september, and avoid the problems of using google
groups?)

On 11/19/2021 10:57 AM, Meredith Montgomery wrote:
>
> Am I looking at the right place, thinking the right thing?
>

`EOF` is a value distinct from any other valid character value. Which
means that in case of a 8-bit char, the total number of distinct
`getchar()` results might reach 257.

That already makes it obvious (per pigeonhole principle) that a 8-bit
`char`, regardless of its signedness and other considerations, is not
sufficient to represent all possible `getchar()` results.

How exactly will this pigeonhole principle manifest itself in a specific
implementation is beside the point.

--
Best regards,
Andrey Tarasevich

On Wednesday, 8 December 2021 at 15:26:37 UTC, dave.d...@gmail.com wrote:

> To Decode get: Daves Old Computers->Personal->Downloads->ENCTXT

So first we need to find "Daves Old Computers" - via a web search?

Then we download and run an executable hosted there, that we know nothing of?

Can you not see the issues in what you've posted?

On 09/12/2021 10:26, Mark Bluemel wrote:
> On Wednesday, 8 December 2021 at 15:26:37 UTC, dave.d...@gmail.com wrote:
>
>> To Decode get: Daves Old Computers->Personal->Downloads->ENCTXT
>
> So first we need to find "Daves Old Computers" - via a web search?
>
> Then we download and run an executable hosted there, that we know nothing of?
>
> Can you not see the issues in what you've posted?
>

There's a ZIP file:

ENCTXT at https://dunfield.themindfactory.com/dnld.htm

which contains C programs to encode and decode, no executables. When I
apply dectxt.c to DD's block of encoded text, I get this C program:

--------------------------------------------------------------
/*
* Tests handling of EOF with signed/unsigned int/char
* result of comp.lang.c posting
*
* Dave Dunfield - https://dunfield.themindfactory.com
*/
#include <stdio.h>

#define TFILE "TMP.DAT" // Temp filename

FILE
*fp;

unsigned char *Vname[] = { // variable type names
"signed int",
"unsigned int",
"signed char",
"unsigned char" };

// 1st test : getc() result stored into var and tested at "same time"
#define TST1(v)\
if((v = getc(fp)) == EOF)\
break;\
Show(v);\
goto a1;

// 2nd test : getc() result stored into var and then that ver is tested
#define TST2(v)\
v = getc(fp);\
Show(v);\
if(v == EOF)\
break;\
goto a1;

// Show a character value (in HEX if not printable)
// Note: Assumes ASCII printable character set!
void Show(unsigned c)
{ printf( ((c < ' ') || (c > '~')) ? "[%x]" : "'%c'", c );
}

// Perform the test on a given variable & test type
void DoTst(unsigned char mode)
{ int Sint;
unsigned int i, Uint;
char Schar;
unsigned char Uchar;

rewind(fp);
i = 0;
printf("%s : %s\n ",
Vname[mode&3],
(mode < 4) ? "if(v=getc()).." : "v=getcc();if(v)..."
);

// In case EOF not detected. try <10 times
a1: if(++i < 10) switch(mode) {
case 0 : TST1(Sint);
case 1 : TST1(Uint);
case 2 : TST1(Schar);
case 3 : TST1(Uchar);
case 4 : TST2(Sint);
case 5 : TST2(Uint);
case 6 : TST2(Schar);
case 7 : TST2(Uchar); }
printf(" =%u\n", i-1);
}

int main()
{ unsigned i;

printf("EOF= %d %x\n", EOF, EOF);

// First create file containing 5 characters
// 'a'0x61, 'b'0x62, 0xFF, 'c'0x63, 'd'0x64
if(!(fp = fopen(TFILE, "wb"))) {
printf("Can't WRITE: %s\n", TFILE);
return 1; }
fputs("ab", fp);
putc(0xFF, fp);
fputs("cd", fp);
fclose(fp);

if(!(fp = fopen(TFILE, "rb"))) {
printf("Can't READ: %s\n", TFILE);
return 2; }

for(i=0; i < 8; ++i)
DoTst(i);

fclose(fp);

return 0;
}

On Wednesday, December 8, 2021 at 10:23:22 PM UTC-5, Tim Rentsch wrote:
> (Incidentally, can you explain why you can't set up a news
> account with one of several few news providers, such as
> eternal-september, and avoid the problems of using google
> groups?)

Just haven't taken the time so far ... looked into setting up some sort of
newsgroup access and spent hours running into various roadblocks... Along
the way I discovered "Google Groups" which would give me access with little
difficulty .. just at the cost of having everything reformatted in a "code
unfriendly" manner...

Years ago I was a fairly active participant in this and other groups but
haven't been in a long time... After what happened (to me) in 2019, I've
essentially retired and having much more time on my hands, wanted to see
what things are like here now so I can determine if it's "worth it" to
"install" clients (seems nothing much "just runs" these days without having
to add lots of stuff to your system) and go through the hassle of getting
access set up elsewhere...

There's no guaranteed that other feeds/readers won't also corrupt source code
format, and "BASE64" might be great, but I don't know how/if every reader
handles it and converts to text in the original format.
(like mentioned above : it's been years since I've accessed groups)

Due to my nature, I still write lots of useful (to me at least) tool, utilities
and test code, and make much if it freely available on my site.
So I wrote ENCTXT to have an easy way to post code in it's original format,
where you won't have to rely on indeterminate third party software (you can
look at/compile DECZIP.C or create your own, as I do document details of the
encoding).

I thought it was "simple enough", all you have to do was grab the archive
mentioned and see the (.TXT format) documents for lots more information.

Ah.. disadvantage of having "formative years" in the 70's/80's, not thinking
"complex enough" for "modern" computing!
(What is the TEXT format ... what do I have to install to be able to view it!)

And just for "case in point", these are NOT complicated sources!
Here is the output of my CSTAT for each (sorry for loss of format):

ENCTXT.C
Characters:
in file(s) : 6139
in comments : 1881
whitespace : 1104
significant : 3154
Lines:
in file(s) : 279
blank/comment: 56
significant : 223
Cism's:
'{'s : 29
'}'s : 29
';'s : 120
comments : 86

DCTXT.C
Characters:
in file(s) : 4850
in comments : 1328
whitespace : 977
significant : 2545
Lines:
in file(s) : 212
blank/comment: 35
significant : 177
Cism's:
'{'s : 18
'}'s : 18
';'s : 99
comments : 71

Regards,
Dave : "Daves Old Computers" -> Personal

> On 09/12/2021 10:26, Mark Bluemel wrote:
> > So first we need to find "Daves Old Computers" - via a web search?

I've found that many sites disallow/remove actual links in posted text, which makes
"finding me" through the link on DavesOldComputers the easiest way to insure it will
get seen... For me at least, my computers related site comes up first when
I Goggle "Daves Old Computers"

> > Then we download and run an executable hosted there, that we know nothing of?
> > Can you not see the issues in what you've posted?

What you might want to do is download and look at the content of the archive.
There is a lot more information there... (assuming you can figure out TEXT :-)
If you choose to compile and run the C sources therein, that is completely up to you.

On Thursday, December 9, 2021 at 6:20:57 AM UTC-5, Brt wrote:
> There's a ZIP file:
>
> ENCTXT at https://dunfield.themindfactory.com/dnld.htm
>
> which contains C programs to encode and decode, no executables. When I
> apply dectxt.c to DD's block of encoded text, I get this C program:

Thanks, didn't think it was too hard! (or perhaps you are extra smart :-)
Formatting was still lost in your posting when I viewed it with GG .. presumably
you got the original C source with tabs and spaces intact!'
(I use tabs at 4-space intervals when coding C ...)

Dave Dunfield : "Daves Old Computers" -> Personal

On 12/9/2021 3:30 PM, Dave Dunfield wrote:
> Just haven't taken the time so far ... looked into setting up some sort of
> newsgroup access and spent hours running into various roadblocks... Along
> the way I discovered "Google Groups" which would give me access with little
> difficulty .. just at the cost of having everything reformatted in a "code
> unfriendly" manner...

Another option, which is extremely simple, is nntp.aioe.org

https://www.aioe.org/

It has limitations on how many posts you can send, but all in all it is
plain simple NNTP, it supports SSL, and it Just Works™

As a newsreader, just use Thunderbird

On 12/8/2021 9:59 PM, Dave Dunfield wrote:
> On Wednesday, December 8, 2021 at 3:16:25 PM UTC-5, Keith Thompson wrote:
>
>>> In case anyone wants to look at: TEST.C
>>> This file is ENCTXTed to protect from online reformatting.
>>> To Decode get: Daves Old Computers->Personal->Downloads->ENCTXT
>>> ...
>> I don't think many people are going to download EXCTXT so they can
>> decode your source file.
>>
>> You can just include code inline in a post. As long as the lines aren't
>> too long it shouldn't be a problem.
>
> Unfortunately, I only have access to newsgroups now through "google groups" which horrendously
> re-formats any text I post... C source I've tried to post "inline" always comes out horrible:
> Spacing removed, lines joined etc.
>
> ENCTXT is an easy way to get the original text, doesn't have to be "installed" etc, I include a DVM binary
> (which can work on Win or Linux "as is") but also the full C source code which I have confirmed compiles
> (and works correctly) with Micro-C, LCC and GCC (and probably lots of other compilers) so you can see
> exactly how it works and what it does... and compile it yourself "to be sure".
>
> And it's only needed if you actually want to look at code I've posted!
>
> Regards,
> Dave
>

You can use pastebin for text.

https://pastebin.com/

Default is "no expiry".

Upload your text.

Collect the URL of the item.

Test in a second browser, that the
text content is preserved as you wished.

Paul

Dave Dunfield <dave.dunfield@gmail.com> writes:

> There's no guaranteed that other feeds/readers won't also corrupt source code
> format, and "BASE64" might be great, but I don't know how/if every reader
> handles it and converts to text in the original format.
> (like mentioned above : it's been years since I've accessed groups)

Do you have any reason to think that Tim does not know how all this
stuff works? If base64 won't work, there's no reason to suppose your
encoding will work. In fact, you know that your encoding does not work,
without extra effort, for the vast majority of newsreaders. I can view
base64 with a few key presses.

> I thought it was "simple enough", all you have to do was grab the
> archive mentioned and see the (.TXT format) documents for lots more
> information.

There is a conventional way to link to many kinds of resource. Your
instructions might be "simple enough", but a direct link is simpler.

> Ah.. disadvantage of having "formative years" in the 70's/80's, not
> thinking "complex enough" for "modern" computing!

Simple is a URL. That's hardly modern (nearly three decades old) nor
complex!

> (What is the TEXT format ... what do I have to install to be able to
> view it!)

No one here has given you any reason to think we are that ignorant.

I was curious, so I went hunting. I found the zip file[1] (though it
might not be the right one) but the included decoding program would not
compile on my system. But that was because I believed the comment in
the zip file: it's not C++ source (as the comment says), it's C99 (or
C90 with C99 comments).

You are making it way too hard.

[1] https://dunfield.themindfactory.com/dnld/ENCTXT.ZIP
--
Ben.

On 09/12/2021 16:05, Ben Bacarisse wrote:
> Dave Dunfield <dave.dunfield@gmail.com> writes:
>
>> There's no guaranteed that other feeds/readers won't also corrupt source code
>> format, and "BASE64" might be great, but I don't know how/if every reader
>> handles it and converts to text in the original format.
>> (like mentioned above : it's been years since I've accessed groups)
>
> Do you have any reason to think that Tim does not know how all this
> stuff works? If base64 won't work, there's no reason to suppose your
> encoding will work. In fact, you know that your encoding does not work,
> without extra effort, for the vast majority of newsreaders. I can view
> base64 with a few key presses.
>
>> I thought it was "simple enough", all you have to do was grab the
>> archive mentioned and see the (.TXT format) documents for lots more
>> information.
>
> There is a conventional way to link to many kinds of resource. Your
> instructions might be "simple enough", but a direct link is simpler.
>
>> Ah.. disadvantage of having "formative years" in the 70's/80's, not
>> thinking "complex enough" for "modern" computing!
>
> Simple is a URL. That's hardly modern (nearly three decades old) nor
> complex!
>
>> (What is the TEXT format ... what do I have to install to be able to
>> view it!)
>
> No one here has given you any reason to think we are that ignorant.
>
> I was curious, so I went hunting. I found the zip file[1] (though it
> might not be the right one) but the included decoding program would not
> compile on my system. But that was because I believed the comment in
> the zip file: it's not C++ source (as the comment says), it's C99 (or
> C90 with C99 comments).

I didn't see any such comments in DECTXT.C.

It compiled for me with no problems on gcc/tcc.

bcc required stdlib.h, string.h, but also it didn't like 'unsigned
char*' types being passed to functions expecting 'char*'; the other
compilers are more lax.

But program worked (I posted the decoded C file).

Getting WAY off topic, thanks to those whom offered helpful suggestions.

I'll respond to a couple of point then "shut up" :-)

>> Do you have any reason to think that Tim does not know how all this
>> stuff works?

No, I don't know who Tim is, but I generally don't trust modern computing
practices is general - I've had too many "helpful updates" to formerly useful
software that made it stop working for me ... so I don't trust anything that
I've not used (and there's a lot) and then only "so far".. it has nothing to
do with "Tim".

Unlike most others, over the 50+ years I've been "doing this", I've written
most of the software I use on a daily basis.

>>If base64 won't work, there's no reason to suppose your
>> encoding will work. In fact, you know that your encoding does not work,
>> without extra effort, for the vast majority of newsreaders. I can view
>> base64 with a few key presses.

Yes, there is minimal extra effort, but I do know it will work and do what I
wanted (might be related to the fact that I wrote it :-)! I don't know that
stuff I've not used will do that, or won't change what it does over time!

>> There is a conventional way to link to many kinds of resource. Your
>> Simple is a URL.

Too many services I've tried to post "how to find me information" to,
don't allow and actively remove email addresses and/or URL links! I've
had to resort to the "find me through DavesOldComputers" method enough
that it has become my default.

>>That's hardly modern (nearly three decades old) nor complex!

This was a bad "joke" - "modern practices" seems (to me) to be more invasive
and aimed more at people who "don't know what they are doing"
(attitude toward users in general, NOT this group).

>>> (What is the TEXT format ... what do I have to install to be able to
>>> view it!)
>> No one here has given you any reason to think we are that ignorant.

Thought I had ended it with a smiley! (sorry) - again, not this group, but I
find a lot of more general "users" don't know things that were common knowledge
"back in the day" - I've sent people information in simple text files and
gotten exactly that question back (what software do I install to view this!)

>> I was curious, so I went hunting. I found the zip file[1] (though it
>> might not be the right one) but the included decoding program would not
>> compile on my system. But that was because I believed the comment in
>> the zip file: it's not C++ source (as the comment says), it's C99 (or
>> C90 with C99 comments).

Most of my code compiles with my own compiler which is essentially K&R C with
a few newer style extensions (like // comments, and in-arglist declarations).
It does also have a couple non-standard extensions which I don't use when
posting "general" code. I usually check with LCC and GCC before I post stuff
I expect others might want to compile!

> bcc required stdlib.h, string.h, but also it didn't like 'unsigned
> char*' types being passed to functions expecting 'char*'; the other
> compilers are more lax.

One of this few things I did't like about the original C spec. is the
assumption that everything is signed unless you explicitly declare it
as "unsigned". Clearly I'm an unusual programmer, because I use far more
"positive only" quantities in my code than places where I need signed.
Having done a LOT of my early work on 16 bit platforms (and compilers),
I found an upper limit of 65535 much better than 32767. And in some
situations signed when you don't need it can cause problems. (refer to
another thread in this group where "isdigit" as a macro generates a warning
about signedness). And some very small cpu architectures actually need more
code to perform a signed compare, which in early "less optimizing days"
meant that:
int i; for(i=0; i < 10; ++i) ...
could generate more code than:
unsigned i; for(i=0; i < 10; ++i) ...
I could go on, but (hopefully) you get the idea of where I "come from".

I would have preferred the attribute to be "signed".

As I've noted previously, many people generally don't like elements of my
style because I tend to declare everything "unsigned" unless I'm actually
working with potentially negative values. Some compilers generate such
warnings because their libraries are written assuming the signed default
types that most programmers use....

Regards,

Dave Dunfield : "Daves Old Computers" -> Personal

Bart <bc@freeuk.com> writes:

> On 09/12/2021 16:05, Ben Bacarisse wrote:
>> Dave Dunfield <dave.dunfield@gmail.com> writes:
>>
>>> There's no guaranteed that other feeds/readers won't also corrupt source code
>>> format, and "BASE64" might be great, but I don't know how/if every reader
>>> handles it and converts to text in the original format.
>>> (like mentioned above : it's been years since I've accessed groups)
>> Do you have any reason to think that Tim does not know how all this
>> stuff works? If base64 won't work, there's no reason to suppose your
>> encoding will work. In fact, you know that your encoding does not work,
>> without extra effort, for the vast majority of newsreaders. I can view
>> base64 with a few key presses.
>>
>>> I thought it was "simple enough", all you have to do was grab the
>>> archive mentioned and see the (.TXT format) documents for lots more
>>> information.
>> There is a conventional way to link to many kinds of resource. Your
>> instructions might be "simple enough", but a direct link is simpler.
>>
>>> Ah.. disadvantage of having "formative years" in the 70's/80's, not
>>> thinking "complex enough" for "modern" computing!
>> Simple is a URL. That's hardly modern (nearly three decades old) nor
>> complex!
>>
>>> (What is the TEXT format ... what do I have to install to be able to
>>> view it!)
>> No one here has given you any reason to think we are that ignorant.
>> I was curious, so I went hunting. I found the zip file[1] (though it
>> might not be the right one) but the included decoding program would not
>> compile on my system. But that was because I believed the comment in
>> the zip file: it's not C++ source (as the comment says), it's C99 (or
>> C90 with C99 comments).
>
> I didn't see any such comments in DECTXT.C.

The comment was from my unzip program, caused by the capital C
extension. I don't use zip files, so I thought it was a comment in the
archive itself.

> It compiled for me with no problems on gcc/tcc.

gcc thought is was C++ as well (again the capital C) and the warnings
that most C compilers will let pass are hard errors in C++. (I thought
you liked hard errors.)

> bcc required stdlib.h, string.h, but also it didn't like 'unsigned
> char*' types being passed to functions expecting 'char*'; the other
> compilers are more lax.
>
> But program worked (I posted the decoded C file).

Yup, that was handy, but the OP could have done that. Or posted a link
to the decoded C file. Or posted a link to a portable ANSI C decoder.
Or posted a link to the zip archive with the decoder in it.

--
Ben.

On 12/9/2021 7:31 AM, Paul wrote:
> On 12/8/2021 9:59 PM, Dave Dunfield wrote:
>> On Wednesday, December 8, 2021 at 3:16:25 PM UTC-5, Keith Thompson wrote:
>>
>>>> In case anyone wants to look at: TEST.C
>>>> This file is ENCTXTed to protect from online reformatting.
>>>> To Decode get: Daves Old Computers->Personal->Downloads->ENCTXT
>>>> ...
>>> I don't think many people are going to download EXCTXT so they can
>>> decode your source file.
>>>
>>> You can just include code inline in a post. As long as the lines aren't
>>> too long it shouldn't be a problem.
>>
>> Unfortunately, I only have access to newsgroups now through "google
>> groups" which horrendously
>> re-formats any text I post... C source I've tried to post "inline"
>> always comes out horrible:
>> Spacing removed, lines joined etc.
>>
>> ENCTXT is an easy way to get the original text, doesn't have to be
>> "installed" etc,  I include a DVM binary
>> (which can work on Win or Linux "as is") but also the full C source
>> code which I have confirmed compiles
>> (and works correctly) with Micro-C, LCC and GCC (and probably lots of
>> other compilers) so you can see
>> exactly how it works and what it does... and compile it yourself "to
>> be sure".
>>
>> And it's only needed if you actually want to look at code I've posted!
>>
>> Regards,
>> Dave
>>
>
> You can use pastebin for text.
>
>    https://pastebin.com/
>
> Default is "no expiry".
>
> Upload your text.
>
> Collect the URL of the item.
>
> Test in a second browser, that the
> text content is preserved as you wished.

My two cents, pastebin works fine, however, it might be nice to include
the raw text. Take a look at the difference between the two following links:

https://pastebin.com/raw/f71480694

vs.

https://pastebin.com/f71480694

;^)

On 09/12/2021 21:26, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 09/12/2021 16:05, Ben Bacarisse wrote:

>>> No one here has given you any reason to think we are that ignorant.
>>> I was curious, so I went hunting. I found the zip file[1] (though it
>>> might not be the right one) but the included decoding program would not
>>> compile on my system. But that was because I believed the comment in
>>> the zip file: it's not C++ source (as the comment says), it's C99 (or
>>> C90 with C99 comments).
>>
>> I didn't see any such comments in DECTXT.C.
>
> The comment was from my unzip program, caused by the capital C
> extension. I don't use zip files, so I thought it was a comment in the
> archive itself.
>
>> It compiled for me with no problems on gcc/tcc.
>
> gcc thought is was C++ as well (again the capital C)

OK, I didn't see that since I copy&pasted the text from inside the ZIP
into a file with lower case '.c'.

(I didn't realise .C was still a thing; I hadn't come across that since
the very first time I tried a C compiler - Visual C in 1992.)

> and the warnings
> that most C compilers will let pass are hard errors in C++. (I thought
> you liked hard errors.)

Yeah, that makes me feel better that my bcc didn't like those
conversions either. I thought it might need to be something else to turn
a blind eye to in 'legacy' mode, my '-old' option.

However the source code was apparently written for use with DD's C
compiler so it may not been intended to be standard.

Also, I've just noticed this comment, after my own includes for these
headers:

#if 0 // These includes may be needed by some compilers
#include <stdlib.h>
#include <string.h>
#endif

This is odd; what would be the problem with just including them anyway?

Dave Dunfield <dave.dunfield@gmail.com> writes:
<cut>

> Unlike most others, over the 50+ years I've been "doing this", I've written
> most of the software I use on a daily basis.

Either you limit what you do with software, or you have spent an
inordinate amount of time re-writing what others have done. Just
thinking about what software I use every day makes my head hurt.

>>> If base64 won't work, there's no reason to suppose your
>>> encoding will work. In fact, you know that your encoding does not work,
>>> without extra effort, for the vast majority of newsreaders. I can view
>>> base64 with a few key presses.
>
> Yes, there is minimal extra effort, but I do know it will work and do
> what I wanted (might be related to the fact that I wrote it :-)! I
> don't know that stuff I've not used will do that, or won't change what
> it does over time!

Your definition of minimal effort is not the same as mine! Also, what
works for you is one thing, but when making public posts, it's worth
considering what will work best for other people.

>>> There is a conventional way to link to many kinds of resource. Your
<There was more material here that got cut. It alters my words.>
>>> Simple is a URL.
>
> Too many services I've tried to post "how to find me information" to,
> don't allow and actively remove email addresses and/or URL links!

What? Posting links is an everyday occurrence on Usenet. Has been for
decades. And you could have posted the link *as well*. One click for
me, hunt down decoder, compile and run for whoever can't see the link
for whatever weird reason.

>>>That's hardly modern (nearly three decades old) nor complex!
>
> This was a bad "joke" - "modern practices" seems (to me) to be more invasive
> and aimed more at people who "don't know what they are doing"
> (attitude toward users in general, NOT this group).

So why not just post a link /along side/ the encoded code?

<cut>
> Most of my code compiles with my own compiler which is essentially K&R
> C with a few newer style extensions (like // comments, and in-arglist
> declarations).

It has all the major hallmarks of post K&R C -- void, function
prototypes, // comments and so on. I can't see what bit of specifically
K&R C you are referring to. I'd call it C90 without const but with C99
in-line comments.

<cut>
>> bcc required stdlib.h, string.h, but also it didn't like 'unsigned
>> char*' types being passed to functions expecting 'char*'; the other
>> compilers are more lax.
>
> One of this few things I did't like about the original C spec. is the
> assumption that everything is signed unless you explicitly declare it
> as "unsigned".

There's two things here. First, the original C spec did not assume that
everything was signed. Specifically, char could be unsigned in K&R C.
Second, char, unsigned char and signed char are three different types.
A (modern) C compiler should report an error when passing an unsigned
char * to a function taking a char *, even if char is unsigned on that
implementation.

--
Ben.

Bart <bc@freeuk.com> writes:

> However the source code was apparently written for use with DD's C
> compiler so it may not been intended to be standard.

Odd, since it's for general, public use. It's a simple text
manipulation program so it shouldn't be hard to make it close to 100%
portable in some widely recognised version of standard C.

> Also, I've just noticed this comment, after my own includes for these headers:
>
> #if 0 // These includes may be needed by some compilers
> #include <stdlib.h>
> #include <string.h>
> #endif
>
> This is odd; what would be the problem with just including them
> anyway?

Very odd.

--
Ben.

On Wednesday, December 8, 2021 at 8:59:08 PM UTC-6, dave.d...@gmail.com wrote:
> On Wednesday, December 8, 2021 at 3:16:25 PM UTC-5, Keith Thompson wrote:
>
> > > In case anyone wants to look at: TEST.C
> > > This file is ENCTXTed to protect from online reformatting.
> > > To Decode get: Daves Old Computers->Personal->Downloads->ENCTXT
> >> ...
> > I don't think many people are going to download EXCTXT so they can
> > decode your source file.
> >
> > You can just include code inline in a post. As long as the lines aren't
> > too long it shouldn't be a problem.
> Unfortunately, I only have access to newsgroups now through "google groups" which horrendously
> re-formats any text I post... C source I've tried to post "inline" always comes out horrible:
> Spacing removed, lines joined etc.
>
> ENCTXT is an easy way to get the original text, doesn't have to be "installed" etc, I include a DVM binary
> (which can work on Win or Linux "as is") but also the full C source code which I have confirmed compiles
> (and works correctly) with Micro-C, LCC and GCC (and probably lots of other compilers) so you can see
> exactly how it works and what it does... and compile it yourself "to be sure".
>
> And it's only needed if you actually want to look at code I've posted!

Commiserations. If it helps, GG only reformats the message text in the viewer.
It posts to usenet whatever you put in the text box unmolested.

For viewing, get a plugin for inserting custom CSS to the page and add this CSS:

html-blob { white-space: pre-wrap; }
html-blob br { display: none; }

If you examine the DOM with something like Firefox's "inspect" tool, you'll see that
(for now) they're simply treating the text as html where the whitespace is no longer
significant and then adding <br> tags after all the newlines. You might consider
also adding "font-family: monospace;" to the html-blob specification. I tried it and
then didn't like it. But for some people, monospace may be preferable.

HTH

Philipp Klaus Krause <pkk@spth.de> writes:

> Am 23.11.21 um 18:43 schrieb Keith Thompson:
>
>> Philipp Klaus Krause <pkk@spth.de> writes:
>>
>>> Am 22.11.21 um 21:55 schrieb Keith Thompson:
>>>
>>>> but useful and non-conforming is
>>>> sometimes better than conforming.
>>>
>>> A 16-bit ptrdiff_t on a freestanding implementation that does not
>>> support objects bigger than (1 << 15) would be another common example.
>>> Though that is only nonconforming for C99, C11 and C17, but valid C90,
>>> C95 and C23.
>>
>> How would it be valid C23? The N2731 draft defines PTRDIFF_WIDTH in
>> <stdint.h> and requires it to be at least 17.
>
> N2808 was voted into C23 on Thursday (conditionally on not causing
> problems for C++, which will be discussed at one of the monthly
> WG14/WG21 liaison meetings).

It is a very sad day for the C programming language.

Dave Dunfield <dave.dunfield@gmail.com> writes:

> On Wednesday, December 8, 2021 at 10:23:22 PM UTC-5, Tim Rentsch wrote:
>
>> (Incidentally, can you explain why you can't set up a news
>> account with one of several few news providers, such as
>> eternal-september, and avoid the problems of using google
>> groups?)
>
> Just haven't taken the time so far ... looked into setting up some
> sort of newsgroup access and spent hours running into various
> roadblocks... Along the way I discovered "Google Groups" which
> would give me access with little difficulty .. just at the cost of
> having everything reformatted in a "code unfriendly" manner...

If you want other people to look at what you're doing it's
important to provide access in a way that _they_ think is easy.

> [...] I've essentially retired and having much more time on my
> hands, [...]

If you have lots of free time, you might practice writing C code
that conforms to the ISO C standard. Good feedback is available
using

gcc -std=c99 -pedantic-errors

On 10/12/2021 10:41, Tim Rentsch wrote:
> Philipp Klaus Krause <pkk@spth.de> writes:
>
>> Am 23.11.21 um 18:43 schrieb Keith Thompson:
>>
>>> Philipp Klaus Krause <pkk@spth.de> writes:
>>>
>>>> Am 22.11.21 um 21:55 schrieb Keith Thompson:
>>>>
>>>>> but useful and non-conforming is
>>>>> sometimes better than conforming.
>>>>
>>>> A 16-bit ptrdiff_t on a freestanding implementation that does not
>>>> support objects bigger than (1 << 15) would be another common example.
>>>> Though that is only nonconforming for C99, C11 and C17, but valid C90,
>>>> C95 and C23.
>>>
>>> How would it be valid C23? The N2731 draft defines PTRDIFF_WIDTH in
>>> <stdint.h> and requires it to be at least 17.
>>
>> N2808 was voted into C23 on Thursday (conditionally on not causing
>> problems for C++, which will be discussed at one of the monthly
>> WG14/WG21 liaison meetings).
>
> It is a very sad day for the C programming language.
>

Do you care to elaborate?

It is irrelevant to all "big" systems, where ptrdiff_t is 32-bit or
more, but it means that C implementations for small systems don't need
to be pointlessly non-conformant. It sounds like a good day to me - an
acknowledgement that C is important on small systems, and that
conformency is important for such small systems.

So IMHO Phillip is to be congratulated on his clear and well-reasoned
proposal. It will make little or no practical difference, but it tidies
up an unnecessary flaw in the way the standards can work for small
embedded systems.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Dave Dunfield <dave.dunfield@gmail.com> writes:
>> On Wednesday, December 8, 2021 at 10:23:22 PM UTC-5, Tim Rentsch wrote:
>>> (Incidentally, can you explain why you can't set up a news
>>> account with one of several few news providers, such as
>>> eternal-september, and avoid the problems of using google
>>> groups?)
>>
>> Just haven't taken the time so far ... looked into setting up some
>> sort of newsgroup access and spent hours running into various
>> roadblocks... Along the way I discovered "Google Groups" which
>> would give me access with little difficulty .. just at the cost of
>> having everything reformatted in a "code unfriendly" manner...
>
> If you want other people to look at what you're doing it's
> important to provide access in a way that _they_ think is easy.
>
>> [...] I've essentially retired and having much more time on my
>> hands, [...]
>
> If you have lots of free time, you might practice writing C code
> that conforms to the ISO C standard. Good feedback is available
> using
>
> gcc -std=c99 -pedantic-errors

If you have a reasonably modern version of gcc, you can use -std=c11 or
-std=c17. (C17 was a minor update on top of C11, and the only
difference between gcc's -std=c11 and -std=c17 options is the value of
__STDC_VERSION__.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Collecting many responses into one pose - sorry if attrition doesn't make
it intact, hopefully you can figure it out - Dave

On Thursday, December 9, 2021 at 5:59:40 PM UTC-5, Ben Bacarisse wrote:
> > Unlike most others, over the 50+ years I've been "doing this", I've written
> > most of the software I use on a daily basis.
> Either you limit what you do with software, or you have spent an
> inordinate amount of time re-writing what others have done. Just
> thinking about what software I use every day makes my head hurt.

-- sorry - Long --

I really have been at this a VERY long time. In the early days I didn't
have the opportunity to use "other" software because it didn't exist. Either
not at all, or not for the numerous systems I designed and built (from scratch)
at the start. I still have my first "commercial system" - a MITS Altair 8800,
after it grew to nearly 64K ram and dual 90k SSSD "North Star" floppies, I did
have the opportunity to make use of other code (North Star DOS being the
first! :-) but by then I had done several more powerful OS's of my own and
had developer most of the software I wanted!

I was (and still am) very fond of assembly language, but it did have "some
issues"... no portability (one CPU) and you had to keep track of a myriad
of "little details" as you coded.. I created a few higher-level "assemblers"
to help address these, but never came up with one I really liked/proffered.

In late 70's a friend gave me a book called "The C Programming Language". A
very new kid on the programming block! It sounded really interesting, here was
a "medium high level" language that would let me do much of what I needed
assembler for, kept track of a LOT of the details, and could easily be ported
to virtually any processor.

I decided to write a compiler for it. I didn't know C at all (learned it
really well while writing the compiler), had never written a "real" compiler
before.. so it did take me a few years... My first Micro-C came out sometime
in the mid-80's. At first it was for the Intel 8080 (my Altair) amd shortly
afterward I did a code generator for the Motorola 6809 - a CPU I was working
with at the time and really likes!

In the next few years, I "ported" my compiler to over a dozen different
CPU architectures (some of them quite "different"). This kept up quite
nicely with my tendency to "build new systems". These variants also proved
to be quite "popular" as I formed DDS and made quite a good living at it
for a fair number of years!

I continued to develop software as much (or perhaps more) than I did before,
but now I was doing it in C and most of it could port to one of my "new system
types" with little more than a recompile!

Since then I've made Micro-C more like certain standards (but never claimed
it to be a "conforming compiler"). I continue to use it very much today,
although it has become MUCH easier to port code I write in Micro-C to other
tools when I have to or it makes sense...

My career was mainly based around very low level, code system type code,
usually for very tiny and unique setups... so I've not needed much I've not
done at least once over the years. I do use third party software when it makes
sense (to me)... I can't be bothered to chase the ever changing "standards" of
web tools and other such "high level modern designs" (dabbled in them lots
though :-)

Unlike most people I know, my most pressing "use" for computing and software is
NOT for "consumption" - it's more about "creation".

>> On 09/12/2021 16:05, Ben Bacarisse wrote:
>> I didn't see any such comments in DECTXT.C.
> The comment was from my unzip program, caused by the capital C
> extension. I don't use zip files, so I thought it was a comment in the
> archive itself.
> gcc thought is was C++ as well (again the capital C)
>OK, I didn't see that since I copy&pasted the text from inside the ZIP
>into a file with lower case '.c'.
>(I didn't realise .C was still a thing; I hadn't come across that since
>the very first time I tried a C compiler - Visual C in 1992.)

Sorry for the confusion. During my "most formative" years, I was mainly
exposed to systems where filenames were ALWAYS upper case. (Even when the
likes of "Windows" began allowing lower-case in file names it wasn't
significant "a.c" was the SAME FILE as "A.C"). When I developed my own
OSes and file system I followed "the norm". And I tend(ed) to code file
names "as they really were" (in upper case).

I wasn't till I began to do some serious work under UNIX that I realized that
system existed where "case matters". Other issues like one (Unix and most of
my OSs) and two (CP/M, DOS, Windows etc) character line endings can also be an
issue.

To deal with this when moving files between systems, I wrote to little tools
to auto rename (to the correct system case) and change line endings of non-
binary files) which I've "gotten used" to just running after importing files
from another system or unpacking and archive...

And since I have no idea where my archives are going to be used, I can't really
do it first! Sorry for forgetting to add notes describing what you might need
to do (Guess I kinda thought people here would be familiar and used to dealing
with such system specific issues).

On Thursday, December 9, 2021 at 8:08:51 PM UTC-5, luser droog wrote:
> Commiserations. If it helps, GG only reformats the message text in the
> viewer. It posts to usenet whatever you put in the text box unmolested.

Thanks! that very helpful to know (being only able to see via GG I could
not confirm or deny this on my own!).

A few months ago when I initially attempted to access this group, I wrote
"RFCGG" (ReFormat C from Google Groups) which helps a LOT (but isn't
perfect :-) and doesn't actually let you see what was originally posted!
(Anyone wanting to see it can look at: CSUCLC.ZIP on my site!)

On Thursday, December 9, 2021 at 5:37:43 PM UTC-5, Bart wrote:
> Also,I've just noticed this comment, after my own includes for these headers:
> #if 0 // These includes may be needed by some compilers
> #include <stdlib.h>
> #include <string.h>
> #endif>
> This is odd; what would be the problem with just including them
> anyway?

I wrote my compiler back in the 80's, as I've tried to explain. it's
essentially K&R at it's core and most everything not explicitly prototyped
defaults to "int" which is the native word-size for the compiler. In other
words, like many early K&R type setups, you don't NEED many prototypes!
These files don't exist in all variations of my toolset. But other more
modern tools complain - hence the #if - my preprocessor will fail if you
attempt to #include a non-existent file.

On Thursday, December 9, 2021 at 5:59:40 PM UTC-5, Ben Bacarisse wrote:
> What? Posting links is an everyday occurrence on Usenet. Has been for
> decades.
As I've tried to explain, I'm "just back" to usenet after "decades".
But I have been involved on many other forums (yeah, there are others!) such
as company sites, local groups... local "for sale" groups for example are bad..
I don't want to "clutter them up" with pages of detailed descriptions and LOTS
of high-res (ie: big) photos, and can't give enough description in the few
short lines they allow... so I put those things on my site, but some groups are
clearly worried you might dispose of something without going through them.. so
they remove all URL's and emails! from your posts!

On Thursday, December 9, 2021 at 5:27:05 AM UTC-5, Mark Bluemel wrote:
> Then we download and run an executable hosted there, that we know nothing of?
> Can you not see the issues in what you've posted?

Ahh.. how quickly they forget!
I've been doing this a LONG time, up till a few years back I was fairly well
known in certain circles (even a bit here). I distributed a LOT of code
(both production and freeware) and have NEVER been accused of or associated
with the distribution of malware!

While I was hospitalized in 2019-20 my long time domain "dunfield.com" expired
and was quickly bought up by a company who has kindly contacted me offering to
rent it back to me! - needless to say, "I declined".

Which leads to...

A friend offered me space on his server... he uses some sort of service,
doesn't have downloads and didn't get a special certificate sold by his
provider... as a result anything I had for download (and I have quite a bit)
which contained an executable of any sort was flagged as "possible malware"
and anyone accessing the site was warned that it contained "bad stuff".

I've since moved my personal site to a different location, and this no longer
happens, but hits are cached "all over" so you might see it from time to time.
Sorry, but there's really nothing I can do!

Love reading about history and tradition.
However, the world goes on and not all changes are for the worse.

A couple of cents:

On 12/10/2021 9:45 PM, Dave Dunfield wrote:
>
> -- sorry - Long --
>

No worries, some of us can still follow a subject beyond half a dozen
lines of text.

>>> On 09/12/2021 16:05, Ben Bacarisse wrote:
>>> I didn't see any such comments in DECTXT.C.
>> The comment was from my unzip program, caused by the capital C
>> extension. I don't use zip files, so I thought it was a comment in the
>> archive itself.
>> gcc thought is was C++ as well (again the capital C)
>> OK, I didn't see that since I copy&pasted the text from inside the ZIP
>> into a file with lower case '.c'.
>> (I didn't realise .C was still a thing; I hadn't come across that since
>> the very first time I tried a C compiler - Visual C in 1992.)
>
> Sorry for the confusion. During my "most formative" years, I was mainly
> exposed to systems where filenames were ALWAYS upper case. (Even when the
> likes of "Windows" began allowing lower-case in file names it wasn't
> significant "a.c" was the SAME FILE as "A.C"). When I developed my own
> OSes and file system I followed "the norm". And I tend(ed) to code file
> names "as they really were" (in upper case).

My personal opinion about gcc's (the community?) convention to interpret
".c" files as C and ".C" files as C++ is that it is somewhat "snob" at
best. I never used that, although I have found myself developing C++
code in ".cc" files and liking that.
That said, I think that case sensitivity in general is a good thing, so
worth adapting to.

>
> I wasn't till I began to do some serious work under UNIX that I realized that
> system existed where "case matters". Other issues like one (Unix and most of
> my OSs) and two (CP/M, DOS, Windows etc) character line endings can also be an
> issue.
>

>
>
> On Thursday, December 9, 2021 at 8:08:51 PM UTC-5, luser droog wrote:
>> Commiserations. If it helps, GG only reformats the message text in the
>> viewer. It posts to usenet whatever you put in the text box unmolested.
>
> Thanks! that very helpful to know (being only able to see via GG I could
> not confirm or deny this on my own!).
>
> A few months ago when I initially attempted to access this group, I wrote
> "RFCGG" (ReFormat C from Google Groups) which helps a LOT (but isn't
> perfect :-) and doesn't actually let you see what was originally posted!
> (Anyone wanting to see it can look at: CSUCLC.ZIP on my site!)
>

That sounds like a lost cause. Trying to follow GG is useless, since
they have repeatedly shown that they'd rather see Usenet die completely
in favor of more profitable platforms - for them, obviously.
Better dump them and adopt some decent newsreader and news server -
there still are some good ones around, and making use of them may help
keep them alive as well.

>
>
> On Thursday, December 9, 2021 at 5:37:43 PM UTC-5, Bart wrote:
>> Also,I've just noticed this comment, after my own includes for these headers:
>> #if 0 // These includes may be needed by some compilers
>> #include <stdlib.h>
>> #include <string.h>
>> #endif>
>> This is odd; what would be the problem with just including them
>> anyway?
>
> I wrote my compiler back in the 80's, as I've tried to explain. it's
> essentially K&R at it's core and most everything not explicitly prototyped
> defaults to "int" which is the native word-size for the compiler. In other
> words, like many early K&R type setups, you don't NEED many prototypes!
> These files don't exist in all variations of my toolset. But other more
> modern tools complain - hence the #if - my preprocessor will fail if you
> attempt to #include a non-existent file.
>

All compilers that I know of will fail in front of a non-existing #include.
But still those two are so basic that that construct really is odd in a
C group.
Not to mention that deprecation of "implicit int" is probably the most
welcomed change that has happened to C since K&R

>
>
> On Thursday, December 9, 2021 at 5:59:40 PM UTC-5, Ben Bacarisse wrote:
>> What? Posting links is an everyday occurrence on Usenet. Has been for
>> decades.
> As I've tried to explain, I'm "just back" to usenet after "decades".
> But I have been involved on many other forums (yeah, there are others!) such
> as company sites, local groups... local "for sale" groups for example are bad..
> I don't want to "clutter them up" with pages of detailed descriptions and LOTS
> of high-res (ie: big) photos, and can't give enough description in the few
> short lines they allow... so I put those things on my site, but some groups are
> clearly worried you might dispose of something without going through them.. so
> they remove all URL's and emails! from your posts!
>

Usenet doesn't do that - because it has no owner :)

>
>
> On Thursday, December 9, 2021 at 5:27:05 AM UTC-5, Mark Bluemel wrote:
>> Then we download and run an executable hosted there, that we know nothing of?
>> Can you not see the issues in what you've posted?
>
> Ahh.. how quickly they forget!
> I've been doing this a LONG time, up till a few years back I was fairly well
> known in certain circles (even a bit here). I distributed a LOT of code
> (both production and freeware) and have NEVER been accused of or associated
> with the distribution of malware!

As far as I can see, that's not the point. No one is questioning honesty
or good faith, but.
From one side the Internet is volatile by nature, and it should be no
surprise that internet reputation follows the same pattern. And there
are just too many scammers and spammers out there to expect anyone to
trust blindly anyone else.
On the other side, there's always the possibility that some system gets
compromised and one of your executables gets affected without you even
being aware of it, if only for a few hours.
You know that, we know that. There are good alternatives, better use them.

>
> While I was hospitalized in 2019-20 my long time domain "dunfield.com" expired
> and was quickly bought up by a company who has kindly contacted me offering to
> rent it back to me! - needless to say, "I declined".

That sucks. Sorry to hear that.

>
> Which leads to...
>
> A friend offered me space on his server... he uses some sort of service,
> doesn't have downloads and didn't get a special certificate sold by his
> provider... as a result anything I had for download (and I have quite a bit)
> which contained an executable of any sort was flagged as "possible malware"
> and anyone accessing the site was warned that it contained "bad stuff".
>
> I've since moved my personal site to a different location, and this no longer
> happens, but hits are cached "all over" so you might see it from time to time.
> Sorry, but there's really nothing I can do!
>
>
>
> Dave Dunfield ::: https://dunfield.themindfactory.com
> Another way to find me: "Daves Old Computers" -> Personal (bottom)

On 10/12/2021 20:45, Dave Dunfield wrote:

> On Thursday, December 9, 2021 at 5:37:43 PM UTC-5, Bart wrote:
>> Also,I've just noticed this comment, after my own includes for these headers:
>> #if 0 // These includes may be needed by some compilers
>> #include <stdlib.h>
>> #include <string.h>
>> #endif>
>> This is odd; what would be the problem with just including them
>> anyway?
>
> I wrote my compiler back in the 80's, as I've tried to explain. it's
> essentially K&R at it's core and most everything not explicitly prototyped
> defaults to "int" which is the native word-size for the compiler. In other
> words, like many early K&R type setups, you don't NEED many prototypes!
> These files don't exist in all variations of my toolset. But other more
> modern tools complain - hence the #if - my preprocessor will fail if you
> attempt to #include a non-existent file.

You could just have an empty string.h for example, or containing a
one-line comment. (Although I'm not sure it's a good idea for string
functions that often take char* to work with 'int', or for a compiler to
not know how many parameters they take.)

> In late 70's a friend gave me a book called "The C Programming
Language". A
> very new kid on the programming block! It sounded really interesting,
here was
> a "medium high level" language that would let me do much of what I needed
> assembler for, kept track of a LOT of the details, and could easily
be ported
> to virtually any processor.
>

I also came across K&R1 long ago, I think in '82, but I had to buy my
copy. However I wasn't quite as enamoured of it as you, and sold it to a
colleague at a significant loss. (It sounds like your friend did the same!)

I decided to continue with my own language instead (which is still going).

I did do a C compiler eventually, but not until 2017.