20 Sep
2020
20 Sep
'20
11 p.m.
Doug McIlroy:
To put it more strongly. this is not a legal C source file.
char *s = NULL;
But this is.
char *s = 0;
Clem Cole:
67)The macro NULL is defined in <stddef.h> (and other headers) as a null
pointer constant; see 7.19.
====
$ cat null.c
char *s = NULL;
$ cat zero.c
char *s = 0;
$
zero.c is a legal C program. null.c is not. Create
files exactly as shown and compile them if you don't
believe me.
Prepend `#include <stddef.h>' (or <stdlib.h> or <stdio.h>)
to null.c and it becomes legal, but I think that's Doug's
point: you need an include file.
Personally I prefer to use NULL instead of 0 when spelling
out a null pointer, because I think it's clearer:
if ((buf = malloc(SIZE)) == NULL)
error("dammit andrew");
though I am willing to omit it when there's no confusion
about = vs ==:
if (*p)
dammit(*p, "andrew");
But that's just a question of style, and Doug's is fine too.
The language does not require the compiler to pre-define
NULL or to recognize it as a keyword; you have to include
an appropriate standard header file.
Norman Wilson
Toronto ON (not 0N nor NULLN)
20 Sep
20 Sep
11:53 p.m.
New subject: reviving a bit of WWB
Norman NULL has to be defined and I said that/showed it. The standard
says where. I was not trying to compile NULL without a definition which I
agree it not legal. If that is what Doug was implying I missed understood
him but I note NULL was introduced in Typesetter C /V7 where those compiler
s set it to 0 in studio but the ANSI/ISO moved it.
On Sun, Sep 20, 2020 at 7:03 PM Norman Wilson <norman(a)oclsc.org> wrote:
Doug McIlroy:
To put it more strongly. this is not a legal C source file.
char *s = NULL;
But this is.
char *s = 0;
Clem Cole:
67)The macro NULL is defined in <stddef.h> (and other headers) as a null
pointer constant; see 7.19.
====
$ cat null.c
char *s = NULL;
$ cat zero.c
char *s = 0;
$
zero.c is a legal C program. null.c is not. Create
files exactly as shown and compile them if you don't
believe me.
Prepend `#include <stddef.h>' (or <stdlib.h> or <stdio.h>)
to null.c and it becomes legal, but I think that's Doug's
point: you need an include file.
Personally I prefer to use NULL instead of 0 when spelling
out a null pointer, because I think it's clearer:
if ((buf = malloc(SIZE)) == NULL)
error("dammit andrew");
though I am willing to omit it when there's no confusion
about = vs ==:
if (*p)
dammit(*p, "andrew");
But that's just a question of style, and Doug's is fine too.
The language does not require the compiler to pre-define
NULL or to recognize it as a keyword; you have to include
an appropriate standard header file.
Norman Wilson
Toronto ON (not 0N nor NULLN)
--
Sent from a handheld expect more typos than usual
21 Sep
21 Sep
midnight
New subject: reviving a bit of WWB
I was also stating (under Henry’s 10th) using a properly defined macro with
the complete cast scheme will be correct and portable to all known
conforming C compilers no matter the target HW architecture — which in a
commercial SW setting is highly valued.
Clem
On Sun, Sep 20, 2020 at 7:53 PM Clem Cole <clemc(a)ccc.com> wrote:
Norman NULL has to be defined and I said that/showed
it. The standard
says where. I was not trying to compile NULL without a definition which I
agree it not legal. If that is what Doug was implying I missed understood
him but I note NULL was introduced in Typesetter C /V7 where those compiler
s set it to 0 in studio but the ANSI/ISO moved it.
On Sun, Sep 20, 2020 at 7:03 PM Norman Wilson <norman(a)oclsc.org> wrote:
Sent from a handheld expect more typos than usual
Doug McIlroy:
To put it more strongly. this is not a legal C source file.
char *s = NULL;
But this is.
char *s = 0;
Clem Cole:
67)The macro NULL is defined in <stddef.h> (and other headers) as a
null
pointer constant; see 7.19.
====
$ cat null.c
char *s = NULL;
$ cat zero.c
char *s = 0;
$
zero.c is a legal C program. null.c is not. Create
files exactly as shown and compile them if you don't
believe me.
Prepend `#include <stddef.h>' (or <stdlib.h> or <stdio.h>)
to null.c and it becomes legal, but I think that's Doug's
point: you need an include file.
Personally I prefer to use NULL instead of 0 when spelling
out a null pointer, because I think it's clearer:
if ((buf = malloc(SIZE)) == NULL)
error("dammit andrew");
though I am willing to omit it when there's no confusion
about = vs ==:
if (*p)
dammit(*p, "andrew");
But that's just a question of style, and Doug's is fine too.
The language does not require the compiler to pre-define
NULL or to recognize it as a keyword; you have to include
an appropriate standard header file.
Norman Wilson
Toronto ON (not 0N nor NULLN)
--
Sent from a handheld expect more typos than usual
-- 
2:24 a.m.
New subject: reviving a bit of WWB
ISO requires that NULL be defined in locale.h, stddef.h, stdio.h, stdlib.h,
string.h, time.h, wchar.h, and their C++ equivalents clocale etc.. It's
pretty unlikely that you can write any useful code at all without NULL
being defined as a side effect.
On Sun, Sep 20, 2020 at 8:01 PM Clem Cole <clemc(a)ccc.com> wrote:
I was also stating (under Henry’s 10th) using a
properly defined macro
with the complete cast scheme will be correct and portable to all known
conforming C compilers no matter the target HW architecture — which in a
commercial SW setting is highly valued.
Clem
On Sun, Sep 20, 2020 at 7:53 PM Clem Cole <clemc(a)ccc.com> wrote:
Norman NULL has to be defined and I said
that/showed it. The standard
says where. I was not trying to compile NULL without a definition which I
agree it not legal. If that is what Doug was implying I missed understood
him but I note NULL was introduced in Typesetter C /V7 where those compiler
s set it to 0 in studio but the ANSI/ISO moved it.
On Sun, Sep 20, 2020 at 7:03 PM Norman Wilson <norman(a)oclsc.org> wrote:
Sent from a handheld expect more typos than usual
Doug McIlroy:
To put it more strongly. this is not a legal C source file.
char *s = NULL;
But this is.
char *s = 0;
Clem Cole:
67)The macro NULL is defined in <stddef.h> (and other headers) as a
null
pointer constant; see 7.19.
====
$ cat null.c
char *s = NULL;
$ cat zero.c
char *s = 0;
$
zero.c is a legal C program. null.c is not. Create
files exactly as shown and compile them if you don't
believe me.
Prepend `#include <stddef.h>' (or <stdlib.h> or <stdio.h>)
to null.c and it becomes legal, but I think that's Doug's
point: you need an include file.
Personally I prefer to use NULL instead of 0 when spelling
out a null pointer, because I think it's clearer:
if ((buf = malloc(SIZE)) == NULL)
error("dammit andrew");
though I am willing to omit it when there's no confusion
about = vs ==:
if (*p)
dammit(*p, "andrew");
But that's just a question of style, and Doug's is fine too.
The language does not require the compiler to pre-define
NULL or to recognize it as a keyword; you have to include
an appropriate standard header file.
Norman Wilson
Toronto ON (not 0N nor NULLN)
--
Sent from a handheld expect more typos than usual
-- 
12:09 a.m.
New subject: reviving a bit of WWB
To two places: stddef.h and stdlib.h :(.
It's interesting to see the different bugs 0, 0L, (char *)0 and (void *)0
expose or hide as definitions of NULL.
0 is fine if sizeof(int) == sizeof(void *). Otherwise varadic function
calls break. 0L is the same, but for long. The pointer definitions run into
trouble in other contexts since NULL is often incorrectly used as a
terminating byte in a string instead of '\0'. (void *) has issues with
const pointers, some of which are relevant if you use it in the wrong
context.
There were quite spirited debates back in the day for which one was best.
They all suck. C++ invented a null pointer symbol because it's type rules
were enough different than C to make a universal NULL #define impossible.
Is that better or worse? Don't know. It's different.
Glad to see the null-pointer need not have all zero bits being different
than a 0 constant shall be the null-pointer in sufficient detail.
Warner
On Sun, Sep 20, 2020, 5:54 PM Clem Cole <clemc(a)ccc.com> wrote:
Norman NULL has to be defined and I said that/showed
it. The standard
says where. I was not trying to compile NULL without a definition which I
agree it not legal. If that is what Doug was implying I missed understood
him but I note NULL was introduced in Typesetter C /V7 where those compiler
s set it to 0 in studio but the ANSI/ISO moved it.
On Sun, Sep 20, 2020 at 7:03 PM Norman Wilson <norman(a)oclsc.org> wrote:
Doug McIlroy:
To put it more strongly. this is not a legal C source file.
char *s = NULL;
But this is.
char *s = 0;
Clem Cole:
67)The macro NULL is defined in <stddef.h> (and other headers) as a
null
pointer constant; see 7.19.
====
$ cat null.c
char *s = NULL;
$ cat zero.c
char *s = 0;
$
zero.c is a legal C program. null.c is not. Create
files exactly as shown and compile them if you don't
believe me.
Prepend `#include <stddef.h>' (or <stdlib.h> or <stdio.h>)
to null.c and it becomes legal, but I think that's Doug's
point: you need an include file.
Personally I prefer to use NULL instead of 0 when spelling
out a null pointer, because I think it's clearer:
if ((buf = malloc(SIZE)) == NULL)
error("dammit andrew");
though I am willing to omit it when there's no confusion
about = vs ==:
if (*p)
dammit(*p, "andrew");
But that's just a question of style, and Doug's is fine too.
The language does not require the compiler to pre-define
NULL or to recognize it as a keyword; you have to include
an appropriate standard header file.
Norman Wilson
Toronto ON (not 0N nor NULLN)
--
Sent from a handheld expect more typos than usual
1:05 a.m.
New subject: reviving a bit of WWB
Yep. They all suck. As Dennis said, “C is quirky” and part of the issue
is HW is even more so. Clem
On Sun, Sep 20, 2020 at 8:10 PM Warner Losh <imp(a)bsdimp.com> wrote:
To two places: stddef.h and stdlib.h :(.
It's interesting to see the different bugs 0, 0L, (char *)0 and (void *)0
expose or hide as definitions of NULL.
0 is fine if sizeof(int) == sizeof(void *). Otherwise varadic function
calls break. 0L is the same, but for long. The pointer definitions run into
trouble in other contexts since NULL is often incorrectly used as a
terminating byte in a string instead of '\0'. (void *) has issues with
const pointers, some of which are relevant if you use it in the wrong
context.
There were quite spirited debates back in the day for which one was best.
They all suck. C++ invented a null pointer symbol because it's type rules
were enough different than C to make a universal NULL #define impossible.
Is that better or worse? Don't know. It's different.
Glad to see the null-pointer need not have all zero bits being different
than a 0 constant shall be the null-pointer in sufficient detail.
Warner
On Sun, Sep 20, 2020, 5:54 PM Clem Cole <clemc(a)ccc.com> wrote:
Sent from a handheld expect more typos than usual
Norman NULL has to be defined and I said
that/showed it. The standard
says where. I was not trying to compile NULL without a definition which I
agree it not legal. If that is what Doug was implying I missed understood
him but I note NULL was introduced in Typesetter C /V7 where those compiler
s set it to 0 in studio but the ANSI/ISO moved it.
On Sun, Sep 20, 2020 at 7:03 PM Norman Wilson <norman(a)oclsc.org> wrote:
-- Doug McIlroy:
To put it more strongly. this is not a legal C source file.
char *s = NULL;
But this is.
char *s = 0;
Clem Cole:
67)The macro NULL is defined in <stddef.h> (and other headers) as a
null
pointer constant; see 7.19.
====
$ cat null.c
char *s = NULL;
$ cat zero.c
char *s = 0;
$
zero.c is a legal C program. null.c is not. Create
files exactly as shown and compile them if you don't
believe me.
Prepend `#include <stddef.h>' (or <stdlib.h> or <stdio.h>)
to null.c and it becomes legal, but I think that's Doug's
point: you need an include file.
Personally I prefer to use NULL instead of 0 when spelling
out a null pointer, because I think it's clearer:
if ((buf = malloc(SIZE)) == NULL)
error("dammit andrew");
though I am willing to omit it when there's no confusion
about = vs ==:
if (*p)
dammit(*p, "andrew");
But that's just a question of style, and Doug's is fine too.
The language does not require the compiler to pre-define
NULL or to recognize it as a keyword; you have to include
an appropriate standard header file.
Norman Wilson
Toronto ON (not 0N nor NULLN)
--
Sent from a handheld expect more typos than usual
5:55 a.m.
New subject: reviving a bit of WWB
On Sun, 20 Sep 2020, Warner Losh wrote:
0 is fine if sizeof(int) == sizeof(void *). Otherwise
varadic function
calls break.
I've never written anything that uses varargs, so I've never run into
that. But I've actually done quite a bit of work with an environment
where this isn't true: MS-DOS using the large or huge model. In this
environment, sizeof(int)=2, and sizeof(void*) is 4.
-uso.
5:59 a.m.
New subject: reviving a bit of WWB
On Sun, Sep 20, 2020, 11:55 PM Steve Nickolas <usotsuki(a)buric.co> wrote:
On Sun, 20 Sep 2020, Warner Losh wrote:
Sizeof(int) == 4 and sizeof(void *) == 8 on LP64 platforms too...
Warner
0 is fine if sizeof(int) == sizeof(void *).
Otherwise varadic function
calls break.
I've never written anything that uses varargs, so I've never run into
that. But I've actually done quite a bit of work with an environment
where this isn't true: MS-DOS using the large or huge model. In this
environment, sizeof(int)=2, and sizeof(void*) is 4.
6:40 p.m.
New subject: reviving a bit of WWB
VAX/VMS was the first operating system I encountered where 0 was not a
valid program address. As was mentioned previously, address space on
early machines was too precious to throw away a whole page of it just
to catch bad null pointer references.
I once saw a C program that depended on 0 being a valid pointer
address, and on a 0x00 byte being at memory address 0. The program
had a bunch of char* pointers that were used in a printf() call,
something like:
printf("%s%s%s%s\n", a, b, c, d);
If you didn't want, say, the third string printed, you assigned NULL
to variable c. That caused c to point to location 0, and printf()
interpreted the 0 byte as the empty string "".
It was hell getting this program to work on the VAX.
-Paul W.
7:56 p.m.
New subject: reviving a bit of WWB
On Mon, Sep 21, 2020 at 2:40 PM Paul Winalski <paul.winalski(a)gmail.com>
wrote:
VAX/VMS was the first operating system I encountered
where 0 was not a
valid program address. As was mentioned previously, address space on
early machines was too precious to throw away a whole page of it just
to catch bad null pointer references.
I once saw a C program that depended on 0 being a valid pointer
address, and on a 0x00 byte being at memory address 0. The program
had a bunch of char* pointers that were used in a printf() call,
something like:
printf("%s%s%s%s\n", a, b, c, d);
If you didn't want, say, the third string printed, you assigned NULL
to variable c. That caused c to point to location 0, and printf()
interpreted the 0 byte as the empty string "".
It was hell getting this program to work on the VAX.
That sounds annoying, but not necessarily insurmountable? I imagine you
could wrap it in something like:
void
print4(char *a, char *b, char *c, char *d)
{
if (a == NULL) a = "";
if (b == NULL) b = "";
if (c == NULL) c = "";
if (d == NULL) d = "";
printf("%s%s%s%s\n", a, b, c, d);
}
?
I guess if it was more complex than that, like say being variadic, it'd be
really annoying because you'd have to walk the arguments and accumulate
them and assign pointers to empty strings as appropriate, or just wrap
printf and interpret the format string.
- Dan C.
8:50 p.m.
New subject: reviving a bit of WWB
On Mon, Sep 21, 2020 at 1:55 AM Steve Nickolas <usotsuki(a)buric.co> wrote:
I've never written anything that uses varargs, so
I've never run into
that. But I've actually done quite a bit of work with an environment
where this isn't true: MS-DOS using the large or huge model. In this
environment, sizeof(int)=2, and sizeof(void*) is 4. Of course, it's not
conformant to pass an int variable as an argument where a pointer variable
is expected.
If the compiler was ISO-conformant (which it almost certainly was not),
that would not matter. 0 in int context would be a 2-byte int with all
bits zero, and 0 in pointer context would be a 4-byte null pointer,
probably with all bits zero.
C doesn't require that the address represented by the null pointer (whether
or not it is all-bits-zero) is inaccessible, merely that there is no C
object or function there. A simple shim of the appropriate size (1, 2, 4,
8 bytes depending on the CPU's alignment rules) will suffice.
9:22 p.m.
New subject: reviving a bit of WWB
Back when we were running v5 at the University of Toronto, we had a
graphics device that we accessed, on our split I&D space 11/45, using 0,
something like this:
struct x {
int reg0, reg1, ...;
};
0->reg1 = 0234;
Several old details of old C made this possible as well: Struct tags were
global, -> worked on any pointer, and ints and pointers were
interchangeable.
-rob
On Tue, Sep 22, 2020 at 6:51 AM John Cowan <cowan(a)ccil.org> wrote:
On Mon, Sep 21, 2020 at 1:55 AM Steve Nickolas <usotsuki(a)buric.co> wrote:
I've never written anything that uses
varargs, so I've never run into
that. But I've actually done quite a bit of work with an environment
where this isn't true: MS-DOS using the large or huge model. In this
environment, sizeof(int)=2, and sizeof(void*) is 4. Of course, it's not
conformant to pass an int variable as an argument where a pointer variable
is expected.
If the compiler was ISO-conformant (which it almost certainly was not),
that would not matter. 0 in int context would be a 2-byte int with all
bits zero, and 0 in pointer context would be a 4-byte null pointer,
probably with all bits zero.
C doesn't require that the address represented by the null pointer
(whether or not it is all-bits-zero) is inaccessible, merely that there is
no C object or function there. A simple shim of the appropriate size (1,
2, 4, 8 bytes depending on the CPU's alignment rules) will suffice.
9:57 p.m.
New subject: reviving a bit of WWB
Right .. I remember running into/using that idiom in a couple of places in
a few other drivers in the early years. I also remember working one of the
CAD tools (it may have been one of the UCB CAD editors) which were very
graphics centric and running into it there.
I always looked at this as part of the original C heritage from simpler
times *i.e.* from ESPOL/BCPL/B and the like, when it was still considered a
'low level' language that mapped well to the HW at hand. As the more and
more features got added, the focus of the language changed ... ney
Chisnall's 2018 screed: C is not a low level language
<https://queue.acm.org/detail.cfm?id=3212479> Not nearly as bad as the
pile we got with 'modern' C++ [which I'm loath to use].
Clem
On Mon, Sep 21, 2020 at 5:23 PM Rob Pike <robpike(a)gmail.com> wrote:
Back when we were running v5 at the University of
Toronto, we had a
graphics device that we accessed, on our split I&D space 11/45, using 0,
something like this:
struct x {
int reg0, reg1, ...;
};
0->reg1 = 0234;
Several old details of old C made this possible as well: Struct tags were
global, -> worked on any pointer, and ints and pointers were
interchangeable.
-rob
On Tue, Sep 22, 2020 at 6:51 AM John Cowan <cowan(a)ccil.org> wrote:
>
>
> On Mon, Sep 21, 2020 at 1:55 AM Steve Nickolas <usotsuki(a)buric.co> wrote:
>
>
>> I've never written anything that uses varargs, so I've never run into
>> that. But I've actually done quite a bit of work with an environment
>> where this isn't true: MS-DOS using the large or huge model. In this
>> environment, sizeof(int)=2, and sizeof(void*) is 4. Of course, it's not
>> conformant to pass an int variable as an argument where a pointer variable
>> is expected.
>>
>
> If the compiler was ISO-conformant (which it almost certainly was not),
> that would not matter. 0 in int context would be a 2-byte int with all
> bits zero, and 0 in pointer context would be a 4-byte null pointer,
> probably with all bits zero.
>
> C doesn't require that the address represented by the null pointer
> (whether or not it is all-bits-zero) is inaccessible, merely that there is
> no C object or function there. A simple shim of the appropriate size (1,
> 2, 4, 8 bytes depending on the CPU's alignment rules) will suffice.
>
>
11:56 p.m.
New subject: reviving a bit of WWB
On Mon, Sep 21, 2020 at 5:57 PM Clem Cole <clemc(a)ccc.com> wrote:
As the more and more features got added, the focus of
the language changed
... ney Chisnall's 2018 screed: C is not a low level language
<https://queue.acm.org/detail.cfm?id=3212479>
Rereading that made me wonder: if someone retargeted an old compiler (pcc,
say) to produce i386 code, how much faster would it run than a VAX? I see
that there is a pcc derivative at <http://pcc.ludd.ltu.se/>, but supposedly
it has been heavily rewritten for C99 compliance and other things.
Not nearly as bad as the pile we got with 'modern' C++ [which I'm loath to
use].
You should be. It's loathsome. :-)
22 Sep
22 Sep
12:54 a.m.
New subject: reviving a bit of WWB
Getting back to the original topic, would this port/refresh of WWB include
style&diction and be redistributable?
21 Sep
21 Sep
9:39 p.m.
New subject: reviving a bit of WWB
On Mon, 21 Sep 2020, John Cowan wrote:
On Mon, Sep 21, 2020 at 1:55 AM Steve Nickolas
<usotsuki(a)buric.co> wrote:
The compiler I used at least tried to be C89. (Borland Turbo C++ 1.01)
I've never written anything that uses
varargs, so I've never run into
that. But I've actually done quite a bit of work with an environment
where this isn't true: MS-DOS using the large or huge model. In this
environment, sizeof(int)=2, and sizeof(void*) is 4. Of course, it's not
conformant to pass an int variable as an argument where a pointer variable
is expected.
If the compiler was ISO-conformant (which it almost certainly was not),
that would not matter. 0 in int context would be a 2-byte int with all
bits zero, and 0 in pointer context would be a 4-byte null pointer,
probably with all bits zero. C doesn't require that the address represented by
the null pointer (whether
or not it is all-bits-zero) is inaccessible, merely that there is no C
object or function there. A simple shim of the appropriate size (1, 2, 4,
8 bytes depending on the CPU's alignment rules) will suffice.
Which was nice with the tiny model: a .COM file organized at near 0x0100,
and iirc, there was guaranteed to be 0xCD 0x20 at 0x0000. (The 8086 "INT
20H" instruction. I just checked in DOSEMU with PC DOS 7, and that is
exactly what shows up there.)
"ANSI C" doesn't mean a lot though when 95% of the code I run across uses
extensions. I still have not successfully kitbashed the Bourne shell onto
native DOS, OS/2 or Windows without an emulation layer - in any form. Did
come *pretty* close with the Forsyth shell but I couldn't work around the
lack of fork() (OS/2 does have a near-exact counterpart for pipe(), but
it's not exposed by the pipe() call for some reason.) I like my Unix
shells even on Microsoft OSes...call me crazy. ;)
-uso.
1314
days inactive
1316
days old
15 comments
9 participants
participants (9)
-
Clem Cole -
Dan Cross -
John Cowan -
norman＠oclsc.org -
Paul Winalski -
Richard Salz -
Rob Pike -
Steve Nickolas -
Warner Losh