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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#163565

On Monday, 22 November 2021 at 10:04:48 UTC, Keith Thompson wrote:
> Mark Bluemel <mark.b...@gmail.com> writes: 
> [...]
> > So, given that C only allows single return values from functions, the return 
> > value from "read()" needs to be able to represent any byte (char) value plus 
> > one other value. So it needs to be bigger than a 'C' char.
> You mean from getchar(), not read().

True - thanks for the correction, Keith.

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

#163585

On Monday, 22 November 2021 at 10:04:48 UTC, Keith Thompson wrote:
> Mark Bluemel <mark.b...@gmail.com> writes: 
> [...]
> > So, given that C only allows single return values from functions, the return 
> > value from "read()" needs to be able to represent any byte (char) value plus 
> > one other value. So it needs to be bigger than a 'C' char.
> You mean from getchar(), not read().
>
getc() / fgetc(). getchar() reads from stdin, which is text. ASCII does in fact
have end of text / end of transmission codes (EXT = 3, EOT = 4).

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

#163586

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 22 November 2021 at 10:04:48 UTC, Keith Thompson wrote:
>> Mark Bluemel <mark.b...@gmail.com> writes: 
>> [...]
>> > So, given that C only allows single return values from functions, the return 
>> > value from "read()" needs to be able to represent any byte (char) value plus 
>> > one other value. So it needs to be bigger than a 'C' char.
>> You mean from getchar(), not read().
>>
> getc() / fgetc(). getchar() reads from stdin, which is text. ASCII does in fact
> have end of text / end of transmission codes (EXT = 3, EOT = 4).

getchar() does read from stdin, but getc() and fgetc() take a FILE*
argument and can easily read from binary streams.

Yes, ASCII does define EXT and EOT characters.  EOT is commonly entered
as Control-D, which typically triggers an end-of-file condition on
Unix-like systems -- but typically those characters when stored in a
file are just treated as ordinary characters (for which iscntrl() will
return a true value).  An EOT character stored in a file is meaningless
(or rather, it has whatever meaning you choose to assign to it).

Few systems use more than a handful of the ASCII control characters with
their originally intended meanings.

-- 
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 */

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

#163596

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On Monday, 22 November 2021 at 10:04:48 UTC, Keith Thompson wrote:
>>> Mark Bluemel <mark.b...@gmail.com> writes: 
>>> [...]
>>> > So, given that C only allows single return values from functions, the return 
>>> > value from "read()" needs to be able to represent any byte (char) value plus 
>>> > one other value. So it needs to be bigger than a 'C' char.
>>> You mean from getchar(), not read().
>>>
>> getc() / fgetc(). getchar() reads from stdin, which is text. ASCII does in fact
>> have end of text / end of transmission codes (EXT = 3, EOT = 4).
>
>getchar() does read from stdin, but getc() and fgetc() take a FILE*
>argument and can easily read from binary streams.
>
>Yes, ASCII does define EXT and EOT characters.  EOT is commonly entered
>as Control-D, which typically triggers an end-of-file condition on
>Unix-like systems -- but typically those characters when stored in a
>file are just treated as ordinary characters (for which iscntrl() will
>return a true value).  An EOT character stored in a file is meaningless
>(or rather, it has whatever meaning you choose to assign to it).
>
>Few systems use more than a handful of the ASCII control characters with
>their originally intended meanings.

Yes, the old protocols for poll-select and contention mode.

[SYN] SOH <ad1> <ad2> <xm> STX <data bytes> ETX BCC

<ad1> <ad2> are two byte poll/select station address.
<xm>  poll vs. select byte.

Still used when accessing obsolete block-mode terminals (I have two
working examples).

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

#163685

On Friday, November 19, 2021 at 1:59:47 PM UTC-5, Meredith Montgomery wrote:

>I did not get Brian Kernighan's concern with setting EOF to a char c.

A bit of an interesting topic. As someone who created a somewhat well
received C compiler "back in the day", here is my $0.02

* Note, I wrote my compiler mid 80's, and although I later updated it to
* support some more modern syntax, it is essentially a K&R compiler.
+ I've not read through all the comments, so sorry if I duplicate.

Lets assume a very simple 16 bit system with byte support:
int = -32768 to 32767 = 0x8000 to 0x7FFF : -1 = 0xFFFF
unsigned int = 0 to 65535 = 0x0000 to 0xFFFF
char = -128 to 127 = 0x80 to 0x7F : -1 = 0xFF
unsigned char = 0 to 255 = 0x00 to 0xFF

Also, lets call signed int/char variables: si/sc
and unsigned int/char variables: ui/uc

getc() must return 16 bits, because a char value of 255 inside a binary
file is NOT EOF.

Assuming 255 is the next byte read:

If you do: uc = getc()
then uc will have 255 which is NOT EOF(-1)

If you do: sc = getc()
then sc will have -1 which IS EOF! (wrong)

** The effect is that if you are reading an ASCII text file where 0xFF
** never occurs, it appears to work correctly.
** But if you are reading a binary file into signed characters (something
** I would never do) it might see EOF instead of 0xFF characters.

If however you do: si = getc()
then si will have 255!

I find in practice with older compilers (including mine), this may
not always "get you". Consider a CPU with registrers R16 and R8:
  if((c = getc()) == EOF) ...
might generate something like:

CALL getc ; 16 bit resuts comes back in R16
STORE lower-half-of R16 to c
CMP R16,0xFFFF ; R16 still has 0xFF
JZ ... ; Not taken!

In this case, because getc() returned int, even though it was stored
in a byte location, the compiler knows it's still an int value and
would probably do full 16 bit compare.

If however:
  c = getc();
  if(c == EOF) ...
You might see something like:

 CALL getc
 STORE lower-half-of R16 to c
 LOAD R8 from c
 CMP R8,0xFF ; now TRUE
 JZ ... ; Now it IS taken!
 
And yes, optimization might prevent the extra load but the compiler would
still do an 8-bit compare - since it's comparing c with -1, 255 is EOF!


Regarding signed .vs. unsigned, I find that many older compilers only
take this into account for magnitude comparisons. Simple == and != would
often work regardless of signededness - this may not apply to more modern
standards where extra code might be generated to caused an unsigned 255
(0xFF) to NOT be the same as a signed -1 (0xFF).. in general I temd not
to trust that they will be different (or the same)!

I worked mainly on (and designed my compiler for) very small embedded
systems.. most "real programmers" dislike my style as I tend to use "unsigned"
and "unsigned char" instead of "int" and "char" when I don't actually
need/want signed values. On very tiny CPUs sign-extension may require more
code than simple zero-extension.

I also don't much rely on signed characters in general. If I want to
know a character is not ASCII (0x00-0x7F) I will usually: if(c & 0x80) ...


-- Interesting but mostly irrevlent note --

This does actually come into play with my C-FLEA, a virtual CPU I designed
to be a fairly optimal target for my compiler with very small code size.
C-FLEA has one "accumulator" which is always 16-bit. 8-bit is only supported
for memory accesses which when used as a value is auto zero-extended.

This means "char" appears as a "signed" positive value between 0 and 255
where "unsigned char" is an unsigned positive value between 0 and 255!
The "signed"/"unsigned" attribute only affects how the compiler propagates
the signededness of results.

Dave

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

#163733

Having nothing better to do this morning, I decided to write a little
test of this for various compilers I have readily available:

  My own Micro-C (DOS and DVM-Win32)
  Borland Turbo-C (DOS)
  LCCwin32 (Win32)
  GCC under (Linux Ubunto 20.10)

The tests simply creates a small (5 byte) file containing
  'a', 'b', 0xFF, 'c' and 'd'
then reads it, testing for EOF with:
  if((var = getc(fp)) = EOF) ...
and also:
	var = getc(fp);
	if(var == EOF) ...
using a 'var' variable of:
	signed int, unsigned int, signed char & unsigned char

Here are the results:
--------------------------------
Micro-C/DOS EOF= -1  FFFF
signed int : if(v=getc())..
  'a''b'[FF]'c''d' =5
unsigned int : if(v=getc())..
  'a''b'[FF]'c''d' =5
signed char : if(v=getc())..
  'a''b'[FFFF]'c''d' =5
unsigned char : if(v=getc())..
  'a''b'[FF]'c''d' =5
signed int : v=getcc();if(v)...
  'a''b'[FF]'c''d'[FFFF] =5
unsigned int : v=getcc();if(v)...
  'a''b'[FF]'c''d'[FFFF] =5
signed char : v=getcc();if(v)...
  'a''b'[FFFF] =2
unsigned char : v=getcc();if(v)...
  'a''b'[FF] =2

Micro-C/DVM EOF= -1  FFFF
signed int : if(v=getc())..
  'a''b'[FF]'c''d' =5
unsigned int : if(v=getc())..
  'a''b'[FF]'c''d' =5
signed char : if(v=getc())..
  'a''b'[FF]'c''d' =5
unsigned char : if(v=getc())..
  'a''b'[FF]'c''d' =5
signed int : v=getcc();if(v)...
  'a''b'[FF]'c''d'[FFFF] =5
unsigned int : v=getcc();if(v)...
  'a''b'[FF]'c''d'[FFFF] =5
signed char : v=getcc();if(v)...
  'a''b'[FF] =2
unsigned char : v=getcc();if(v)...
  'a''b'[FF] =2

Turbo-C EOF= -1  ffff
signed int : if(v=getc())..
  'a''b'[ff]'c''d' =5
unsigned int : if(v=getc())..
  'a''b'[ff]'c''d' =5
signed char : if(v=getc())..
  'a''b' =2
unsigned char : if(v=getc())..
  'a''b'[ff]'c''d'[ff][ff][ff][ff] =9
signed int : v=getcc();if(v)...
  'a''b'[ff]'c''d'[ffff] =5
unsigned int : v=getcc();if(v)...
  'a''b'[ff]'c''d'[ffff] =5
signed char : v=getcc();if(v)...
  'a''b'[ffff] =2
unsigned char : v=getcc();if(v)...
  'a''b'[ff]'c''d'[ff][ff][ff][ff] =9

LCC: EOF= -1  ffffffff
signed int : if(v=getc())..
  'a''b'[ff]'c''d' =5
unsigned int : if(v=getc())..
  'a''b'[ff]'c''d' =5
signed char : if(v=getc())..
  'a''b' =2
unsigned char : if(v=getc())..
  'a''b'[ff]'c''d'[ff][ff][ff][ff] =9
signed int : v=getcc();if(v)...
  'a''b'[ff]'c''d'[ff] =5
unsigned int : v=getcc();if(v)...
  'a''b'[ff]'c''d'[ff] =5
signed char : v=getcc();if(v)...
  'a''b'[ff] =2
unsigned char : v=getcc();if(v)...
  'a''b'[ff]'c''d'[ff][ff][ff][ff] =9

GCC: EOF= -1  ffffffff
signed int : if(v=getc())..
  'a''b'[ff]'c''d' =5
unsigned int : if(v=getc())..
  'a''b'[ff]'c''d' =5
signed char : if(v=getc())..
  'a''b' =2
unsigned char : if(v=getc())..
  'a''b'[ff]'c''d'[ff][ff][ff][ff] =9
signed int : v=getcc();if(v)...
  'a''b'[ff]'c''d'[ffffffff] =5
unsigned int : v=getcc();if(v)...
  'a''b'[ff]'c''d'[ffffffff] =5
signed char : v=getcc();if(v)...
  'a''b'[ffffffff] =2
unsigned char : v=getcc();if(v)...
  'a''b'[ff]'c''d'[ff][ff][ff][ff] =9
--------------------------------

Some "interesting" notes:

Both Micro-C and Turbo-C are 16 bit compiler, LCC and GCC are 32 bit.

In all cases, EOF appears to have a value of -1

Micro-C does not do "extra work" to compare char (byte) variables. This is
mainly because it was designed with VERY small systems in mind (limited word
operations and often not much code storage space). In these cases "char"
variables are used a LOT and Micro-C generates only byte operations in
expressions having only 8 bit types.

Due to it's C-FLEA CPU, in Micro-C/DVM, "char" is treated as 16-bit signed
positive value between 0-255.

Other compilers appear to be doing more with "char" values, sign extending
them or EOF is defined in such a way it cannot be interpreted as a byte (-1
can be a byte).

Also, Micro-C keep the type/content of an expression when a partial result
is stored into a different type "part way along". Some other compilers
appear to treat the whole result differently when when this happens...


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
----------------------------------------------------------------------
7u7p7J7f7p7f8T8k8y8z8y7f8n8g8t8j8r8o8t8m7f8u8l7f8E8O8F7f828o8z8n7f8y8o
8m8t8k8j7u808t:v:g7f8o8t8z7u8i8n8g8x:::B7I8x8k8y808r8z:P:T8i8u8s8v7t8r
8g8t8m7t8i7f8v8u8y8z:::Q:::B:P:B8D8g818k7f8D808t8l8o8k8r8j7f7f7f7s::At
8n8z8z8v8y757u7u8jA:Am7t8z8n8k8s8o8t8j8l8g8i8z8u8x847t::AG:::B7u7J7i8o
8t8i8r808j8k7f778y8z8j8o8u7t8n797J7J7i8j8k8l8o8t8k7I8T8F8I8L8E7I7h8T8M
8P7t8D8A8T7h7I7I7u7u:::E8s8v7f8l8o8r8k8t8g8s8k7J7J:PB57J7I7p8l8v767J7J
Af:n:P:07f7p8V:PCV8a8c7f787f86:fCH818g8x8o8g8h8r8k7f8z848v8k7f:PCV8y7J
7I7hAv:p7h7r::DZBP:n:fDmB:CpBvDm:fED7f88::Ck::CJ7w8y8z7f8z:::G7f757f8m
8k8z8i7n7o7fA::88y::BP:v:t8u:PDF7f:::M:fEl:::t8g8z7f7h8y::CW7f8z8o8s8k
7hAvBv8S8T7w7n817o8b7J7I8o8l7n7n81::C9:fEt8l8v7o7o7f7878:P:W:PFz7I8h8x
8k8g8q76::F08S8n8u82::Fx:PGZ8m8u::FE8g7w:vEc7xA:FMHvEq8n8k8t::Hh::FW81
8k8x7f8o8yA:FOBPFk7x:vFxBPF7C:GZ::F3::F7D:GKBfGo:PGd7f8g:fCv::BN::Ht81
8g8r808k7f7n8o8t7f8H8E8X7f8o8l7f8t8u8z7f8v8x:::w:PDK7o:PEe8N8u8z8k757f
8A8y8y80::DW7f8A8S8C8I8IAvJyB:JT8y8k8z7g7J818u8o8j:fJM7nAvCn7o7J867J7I
:fJz8l7n7f7n7n8i7f777f7m7f7m7o7f87877f::LQ797f7m897m::GG7;7f7h8a7k838c
7h::Eq7h7m7k8i7m7h7r7f8i7f7o767J88:fEd8P8k8x8l8u8x8s:PHh:vEl8u8t::JR8m
8o81::HkAfDG7l:vEl:PDP:vKt8D8u8T8y8zB:K3:PCx8s8u8j::J7::LE:::w7f8S:::w
767J7IBP:n7f8o7r7f8U:vNe:fCw8S:P:0BPNh:fCw8U:vOB7J:::782::BJ:fIU::F1::
C97v::NhA:LH7h7k8y::Eq7k8y8b8t7f7f:PDm7I:vC2:PNQ7l7y8c:PPI7n:PNQ::LS7z
:fLm:PIn78:vEt7o7t7t:fLv:vPu::Ew76:PIn::P27t7h::GR::L97J:PCI8I8t7f8i8g
8y8k:f:W:PJv8j8k8z8k::JZ8j7t7f8z8x847f777w7v:fFe8y7J8g7w75:PF27q7q8o::
LS7w7v7o7f8y:::b8i8n:fPd7o7f::LE7I:fQf7v7I75:vFs:PNd:POo:vRl7wAPRs:PN0
AvR47xAfRs:P:0AvR47yAfSDBvSj7z:vRs7xC:Rz70APTKBvSL71AfTKBvSj72AfTh:vSj
7I88AvOy7f787k808b8t::L48o7s7w:vL9:PNZ8s8g8o8t7n:fLCAv:n:PObAPO0:::X78
7f7k::As7k83:fUv:::X:fVvAPQU8F8o8x::Ej8i::GV8z8k:fCQ::AF::J28o8t:P:Q70
AvJT::DY7u7u7I7f7m8g7m7v83717w7r7f7m8h:PWy7x7r7f7v838F::Vz7m8i:PWy7y::
W38j:PWy7z:fF17g::GD::C98l8u8v8k8t7n:fB47r7f7h828h7h7o::GG:PRiAPO08C8g
8t7m8z7f8W8R8I8T8E:vP:::L4:fB4:fR48x8k8z808x8t7f7w767f::Ug8l8v808z8y7n
7h8g8h::L4:vOm::Yx8i7n:vXC:vOmA:Yw8i8jAfY58l8i8r8u8y8k:vOlEvXY8xEPXz8R
8E8A8DEvYQ7x:PYr::Yu8u8x7n8o787v767f:PRN73767f::RL7o::GR:vM88o:fQUBvZl
A:Yj::Ow887J
----------------------------------------------------------------------

Regards,
Dave - see "Daves Old computers" -> Personal

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

#163734

Dave Dunfield <dave.dunfield@gmail.com> writes:
> Having nothing better to do this morning, I decided to write a little
> test of this for various compilers I have readily available:
>
>   My own Micro-C (DOS and DVM-Win32)
>   Borland Turbo-C (DOS)
>   LCCwin32 (Win32)
>   GCC under (Linux Ubunto 20.10)
>
> The tests simply creates a small (5 byte) file containing
>   'a', 'b', 0xFF, 'c' and 'd'
> then reads it, testing for EOF with:
>   if((var = getc(fp)) = EOF) ...
> and also:
> 	var = getc(fp);
> 	if(var == EOF) ...
> using a 'var' variable of:
> 	signed int, unsigned int, signed char & unsigned char
>
> Here are the results:
[SNIP]

> 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
> ----------------------------------------------------------------------
> 7u7p7J7f7p7f8T8k8y8z8y7f8n8g8t8j8r8o8t8m7f8u8l7f8E8O8F7f828o8z8n7f8y8o
> 8m8t8k8j7u808t:v:g7f8o8t8z7u8i8n8g8x:::B7I8x8k8y808r8z:P:T8i8u8s8v7t8r
[...]
> 8E8A8DEvYQ7x:PYr::Yu8u8x7n8o787v767f:PRN73767f::RL7o::GR:vM88o:fQUBvZl
> A:Yj::Ow887J
> ----------------------------------------------------------------------

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.  If absolutely necessary, you can
use a standard encoding like base64.

-- 
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 */

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

#163735

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

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

#163736

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?)

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

#163742

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

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

#163745

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

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

#163747

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.

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

#163748

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

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

#163750

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

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

#163754

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.

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

#163751

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.

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

#163753

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?

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

#163755

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.

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

#163762

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

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

#163772

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 */

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

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

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

csiph-web