Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #163505 > unrolled thread

K&R, 2nd edition, Brian's concerns with ``char c = EOF''

Back to article view | Back to comp.lang.c

Contents

  K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Meredith Montgomery <mmontgomery@levado.to> - 2021-11-19 15:57 -0300
    Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-19 12:21 -0800
      Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Meredith Montgomery <mmontgomery@levado.to> - 2021-11-19 18:14 -0300
        Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-19 14:10 -0800
          Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Meredith Montgomery <mmontgomery@levado.to> - 2021-11-20 17:30 -0300
          Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' scott@slp53.sl.home (Scott Lurndal) - 2021-11-21 16:01 +0000
      Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Philipp Klaus Krause <pkk@spth.de> - 2021-11-22 11:23 +0100
        Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-22 12:55 -0800
          Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Philipp Klaus Krause <pkk@spth.de> - 2021-11-23 17:04 +0100
            Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-23 09:43 -0800
              Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 11:26 +0100
                Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-10 01:41 -0800
                  Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' David Brown <david.brown@hesbynett.no> - 2021-12-10 14:40 +0100
    Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Barry Schwarz <schwarzb@delq.com> - 2021-11-19 12:22 -0800
      Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Meredith Montgomery <mmontgomery@levado.to> - 2021-11-19 18:10 -0300
      Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' David Brown <david.brown@hesbynett.no> - 2021-11-20 13:24 +0100
        Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Meredith Montgomery <mmontgomery@levado.to> - 2021-11-20 17:32 -0300
    Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Mark Bluemel <mark.bluemel@gmail.com> - 2021-11-22 00:27 -0800
    Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Mark Bluemel <mark.bluemel@gmail.com> - 2021-11-22 00:34 -0800
      Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-22 02:04 -0800
        Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Mark Bluemel <mark.bluemel@gmail.com> - 2021-11-22 02:46 -0800
        Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-11-22 21:22 -0800
          Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-22 22:03 -0800
            Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' scott@slp53.sl.home (Scott Lurndal) - 2021-11-23 14:52 +0000
    Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Dave Dunfield <dave.dunfield@gmail.com> - 2021-11-26 07:31 -0800
      Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-08 07:26 -0800
        Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-08 12:16 -0800
          Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-08 18:59 -0800
            Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-08 19:23 -0800
              Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-09 06:30 -0800
                Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Manfred <noname@add.invalid> - 2021-12-09 16:10 +0100
                Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-09 16:05 +0000
                  Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Bart <bc@freeuk.com> - 2021-12-09 17:41 +0000
                    Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-09 12:24 -0800
                      Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-09 22:59 +0000
                    Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-09 21:26 +0000
                      Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Bart <bc@freeuk.com> - 2021-12-09 22:37 +0000
                        Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-09 23:09 +0000
                Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-10 01:58 -0800
                  Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-10 10:46 -0800
                    Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-12 08:21 -0800
            Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Paul <nospam@needed.invalid> - 2021-12-09 10:31 -0500
              Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-09 13:32 -0800
            Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' luser droog <luser.droog@gmail.com> - 2021-12-09 17:08 -0800
              Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-10 12:45 -0800
                Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Manfred <noname@add.invalid> - 2021-12-11 19:17 +0100
                Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Bart <bc@freeuk.com> - 2021-12-11 23:19 +0000
                Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-15 00:31 -0800
        Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Mark Bluemel <mark.bluemel@gmail.com> - 2021-12-09 02:26 -0800
          Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Bart <bc@freeuk.com> - 2021-12-09 11:20 +0000
            Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-09 06:50 -0800
    Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-12-08 20:00 -0800
    Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Kaz Kylheku <480-992-1380@kylheku.com> - 2021-12-12 18:55 +0000
      Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-12-12 14:38 -0500

Page 3 of 3 — ← Prev page 1 2 [3]

#163800

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> 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__.)

I deliberately chose C99 because I think it's the best fit
for the suggestion given.

[toc] | [prev] | [next] | [standalone]

#163746

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

[toc] | [prev] | [next] | [standalone]

#163752

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

;^)

[toc] | [prev] | [next] | [standalone]

#163756

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

[toc] | [prev] | [next] | [standalone]

#163775

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!



Dave Dunfield ::: https://dunfield.themindfactory.com
Another way to find me: "Daves Old Computers" -> Personal (bottom)

[toc] | [prev] | [next] | [standalone]

#163790

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)

[toc] | [prev] | [next] | [standalone]

#163796

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.

[toc] | [prev] | [next] | [standalone]

#163841

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

> [...]

For future reference here is a short C program that does
base64 encoding.


/***  b64e.c - base64 encode stdin to stdout.             */
/***  NOTE:  This program assumes characters are 8 bits.  */

#include <stdio.h>

static char A[] = {
  "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"
};

int
main( void ){
    int c;
    unsigned long  b = 0,  n = 0,  k = 0;
    char out[ 73 ];

    while(  c = getchar(),  c != EOF  ){
        b = (b<<8) + c,  n += 8;
        do {
            if(  k > 71  )  out[k] = 0,  puts( out ),  k = 0;
            n -= 6;
            out[ k++ ] = A[ b >>n &63 ];
        } while(  n > 5  );
    }

    if(  n > 0  )  out[ k++ ] = A[ b <<(6-n) &63 ];

    if(  k > 0  )  out[k] = 0,  puts( out ),  k = 0;
    else           puts( "====" );

    return  0;
}

[toc] | [prev] | [next] | [standalone]

#163738

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?

[toc] | [prev] | [next] | [standalone]

#163739

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;
}

[toc] | [prev] | [next] | [standalone]

#163743

> 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

[toc] | [prev] | [next] | [standalone]

#163737

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

[toc] | [prev] | [next] | [standalone]

#163805

On 2021-11-19, Meredith Montgomery <mmontgomery@levado.to> wrote:
> I did not get Brian Kernighan's concern with setting EOF to a char c.
> The context is
>
>   char c = getchar();
>
> And Kernighan says:
>
> --8<---------------cut here---------------start------------->8---
> We must declare c to be a type big enough to hold any value that getchar
> returns. We can't use char since c must be big enough to hold EOF in
> addition to any possible char . Therefore we use int.
> --8<---------------cut here---------------end--------------->8---

Not all of this is correct. The conclusion to use int is correct,
but it is incorrect to insinuate that:

- EOF is distinct from values of char (it isn't required to be,
  and quite often isn't: char is often signed, and EOF is often #defined
  as -1).

- getchar() returns values of char (it doesn't; if a datum is available
  from the stream, it returns it as a value from 0 to UCHAR_MAX).

Is the quote verbatim?

Also, the primary reason to capture the return value of getchar, getc
and fgetc using a value of type int is that this is the declared
return type of these functions.

If a function returns int, you capture that with int, or else (if
you have special reasons for it) an integer type whose range is a
superset of int. Your choice need not, and ideally should not, be
justified with the run-time semantics of the function; you know
from the type that you're capturing every value.

(To handle the value futher, you have to know something about its
semantics, like which subset of its range represents a datum and which
value(s) are in-band error signaling.)

> So I can't be sure a char would always be signed, for example.  I can't
> be sure EOF would fit in a char.

It is overwhelmingly common for EOF to have a value that is
representable in a char (informally, to "fit" into a char).

And that would be a problem if getchar returned char values,
and one not solved by the int return type.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

[toc] | [prev] | [next] | [standalone]

#163806

On 12/12/21 1:55 PM, Kaz Kylheku wrote:
...
> Not all of this is correct. The conclusion to use int is correct,
> but it is incorrect to insinuate that:
> 
> - EOF is distinct from values of char (it isn't required to be,
>   and quite often isn't: char is often signed, and EOF is often #defined
>   as -1).

You're quite correct that EOF isn't required to be distinct from valid
values - but it's also much more convenient if it is distinct. I think
you'll find that systems where char is signed are generally also systems
where EOF != -1.

The implementations where there's a real problem are those where it's
not possible for EOF to be a distinct value. For example, that would be
the case if UCHAR_MAX > INT_MAX (which requires that CHAR_BIT >= 16).

All standard I/O is defined as behaving as if it ultimately involves
calls to fputc() or fgetc(). fputc() is defined as converting from int
to unsigned char; fgetc() is defined as reversing that conversion. In
general, conversion a value that's too large to be represented in the
new type either produces an implementation-defined result, or raises an
implementation-defined signal.

However, "Data read in from a binary stream shall compare equal to the
data that were earlier written out to that stream, under the same
implementation." Therefore, if you call fputc(EOF, binary_stream), a
call to fgetc() which reads that byte must return EOF, without actually
being at the end of a file. This is true, regardless of which value the
implementation chooses for EOF. On such systems, you must check feof()
and ferr() to determine whether eis

> - getchar() returns values of char (it doesn't; if a datum is available
>   from the stream, it returns it as a value from 0 to UCHAR_MAX).

It's read in as unsigned char, but converted to int; in the unlikely
event that UCHAR_MAX > INT_MAX, that conversion will change the value.

>> So I can't be sure a char would always be signed, for example.  I can't
>> be sure EOF would fit in a char.
> 
> It is overwhelmingly common for EOF to have a value that is
> representable in a char (informally, to "fit" into a char).

Not on systems where char is unsigned.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web