On Thu, 29 Feb 2024 08:58:40 +0100, David Brown wrote:

> On 28/02/2024 21:56, Lawrence D'Oliveiro wrote:
>>
>> On Wed, 28 Feb 2024 12:50:10 +0100, David Brown wrote:
>>
>>> ... people write utilities for them in a variety of languages ...
>>>
>>> But it will often be more convenient to have it built into the
>>> language and compiler.
>>
>> What can be built into the language can only ever be a small subset of
>> the many and varied ways that people have incorporated data blobs into
>> their programs.
>
> Of course. But that doesn't mean that a language should not include a
> feature that makes it easy for a lot of people to get some data blobs
> into their code.

Maybe the C compiler should concentrate on compiling C code, and leave it
to the rest of the build toolchain to deal with other data.

On 2/29/2024 7:22 AM, Richard Harnden wrote:
> On 29/02/2024 14:31, bart wrote:
>> On 28/02/2024 21:36, Keith Thompson wrote:
>>> bart <bc@freeuk.com> writes:
>>> [...]
>>>> AFAIK strings in C can have embedded zeros when not assumed to be
>>>> zero-terminated. So here:
>>>>
>>>>      char s[]={1,2,3,0,4,5,6};
>>>>
>>>> s will have a length of 7.
>>>
>>> Strings *by definition* cannot have embedded zeros.  A null character
>>> terminates a string.
>>>
>>> A string literal can have embedded \0 characters, but if you're
>>> suggesting that #embed should expand to a string literal, I can see
>>> several disadvantages and no significant advantages.  For one thing, the
>>> data may or may not end with a null character; string literals always
>>> do.
>>
>> Not here:
>>
>>      char s[]  = "ABC";
>>      char t[3] = "DEF";
>>
>> The "DEF" string doesn't end with a zero.
>
> And is, therefore, not a string.
[...]

Right. However, is this a string or two embedded strings:

char x[] = "ABC\0DEF"
_____________________
#include <stdio.h>

int main()
{ char x[] = "ABC\0DEF";

printf("%s\n", x);
printf("%s", x + 4);

return 0;
} _____________________

Any undefined behavior here?

scott@slp53.sl.home (Scott Lurndal) writes:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>On 29.02.2024 17:17, Scott Lurndal wrote:
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>> On 29.02.2024 16:48, Scott Lurndal wrote:
>>>>>
>>>>> int main(int b,char**i){long long n=B,a=I^n,r=(a/b&a)>>4,y=atoi(*++i),_=(((a^n/b)*(y>>T)|y>>S)&r)|(a^r);printf("%.8s\n",(char*)&_);}
>>>>
>>>> What does it do?
>>>>
>>>> What preconditions must be fulfilled or what additions
>>>> does it need to compile?
>>
>>With the link below I see it "needs" a 600+ lines long Makefile.
>
> The readme simply says compile it and run it
> as ./prog <value between 1 and 512>.

No, you have to compile it with specific command-line arguments to
define B and I. The Makefile does that (don't ask me why it's so long),
but you can do it manually.

From hint.txt:
"""
On a little-endian machine:

clang -include stdio.h -include stdlib.h -Wall -Weverything -pedantic -DB=6945503773712347754LL -DI=5859838231191962459LL -DT=0 -DS=7 -o prog prog.c

On a big-endian machine:

clang -include stdio.h -include stdlib.h -Wall -Weverything -pedantic -DB=7091606191627001958LL -DI=6006468689561538903LL -DT=1 -DS=0 -o prog.be prog.c
"""

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

On Thu, 29 Feb 2024 18:09:52 GMT, Scott Lurndal wrote:

> I have an actual use case today where #embed of a (C++) std::map binary
> object created by separate tool would be very useful. I'm planning on
> using mmap to load it at runtime at the moment.

Why not convert it to a .o file and statically link it into your program
as part of the build process?

On Thu, 29 Feb 2024 16:19:45 +0100, David Brown wrote:

> An array of bytes is not a "string".

It is in PHP, I think also in Perl, and also in (obsolete) Python 2.

And what about C string functions that take explicit lengths?

On 29/02/2024 21:20, Keith Thompson wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>> On 29.02.2024 17:17, Scott Lurndal wrote:
>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>>> On 29.02.2024 16:48, Scott Lurndal wrote:
>>>>>>
>>>>>> int main(int b,char**i){long long n=B,a=I^n,r=(a/b&a)>>4,y=atoi(*++i),_=(((a^n/b)*(y>>T)|y>>S)&r)|(a^r);printf("%.8s\n",(char*)&_);}
>>>>>
>>>>> What does it do?
>>>>>
>>>>> What preconditions must be fulfilled or what additions
>>>>> does it need to compile?
>>>
>>> With the link below I see it "needs" a 600+ lines long Makefile.
>>
>> The readme simply says compile it and run it
>> as ./prog <value between 1 and 512>.
>
> No, you have to compile it with specific command-line arguments to
> define B and I. The Makefile does that (don't ask me why it's so long),
> but you can do it manually.
>
> From hint.txt:
> """
> On a little-endian machine:
>
> clang -include stdio.h -include stdlib.h -Wall -Weverything -pedantic -DB=6945503773712347754LL -DI=5859838231191962459LL -DT=0 -DS=7 -o prog prog.c
>
> On a big-endian machine:
>
> clang -include stdio.h -include stdlib.h -Wall -Weverything -pedantic -DB=7091606191627001958LL -DI=6006468689561538903LL -DT=1 -DS=0 -o prog.be prog.c
> """

In't it cheating when half the program is part of the build
instructions? Here is a complete standalone program:

----------------
#include <stdio.h>
#include <stdlib.h>
#define B 6945503773712347754LL
#define I 5859838231191962459LL
#define T 0
#define S 7
int main(int b,char**i){long long
n=B,a=I^n,r=(a/b&a)>>4,y=atoi(*++i),_=(((a^n/b)*(y>>T)|y>>S)&r)|(a^r);printf("%.8s\n",(char*)&_);}
----------------

It's 261 bytes. The 'one-liner' that was posted was 134 bytes.

(It appears to print an input of 0 to 255 as binary.)

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 2/29/2024 7:22 AM, Richard Harnden wrote:
>> On 29/02/2024 14:31, bart wrote:
[...]
>>> Not here:
>>>
>>>      char s[]  = "ABC";
>>>      char t[3] = "DEF";
>>>
>>> The "DEF" string doesn't end with a zero.
>> And is, therefore, not a string.
> [...]
>
> Right. However, is this a string or two embedded strings:
>
> char x[] = "ABC\0DEF"

Is *what* a string or two embedded strings?

x as a whole does not contain a string, but there are 8 strings within it.

> _____________________
> #include <stdio.h>
>
> int main()
> {
> char x[] = "ABC\0DEF";
>
> printf("%s\n", x);
> printf("%s", x + 4);
>
> return 0;
> }
> _____________________
>
> Any undefined behavior here?

No, and none in this:

for (size_t i = 0; i < sizeof x; i ++) {
printf("%s\n", x+i);
}

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

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Thu, 29 Feb 2024 16:19:45 +0100, David Brown wrote:
>> An array of bytes is not a "string".
>
> It is in PHP, I think also in Perl, and also in (obsolete) Python 2.

I'm fairly sure that strings are of a distinct non-array type in all
three of those languages. If you're curious about the details, consult
the relevant documentation or post in an appropriate newsgroup.

> And what about C string functions that take explicit lengths?

What about them?

The C standard defines the term "string" (7.1.1 paragraph 1). Do you
dispute that definition?

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

On 2/29/2024 1:45 PM, Keith Thompson wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 2/29/2024 7:22 AM, Richard Harnden wrote:
>>> On 29/02/2024 14:31, bart wrote:
> [...]
>>>> Not here:
>>>>
>>>>      char s[]  = "ABC";
>>>>      char t[3] = "DEF";
>>>>
>>>> The "DEF" string doesn't end with a zero.
>>> And is, therefore, not a string.
>> [...]
>>
>> Right. However, is this a string or two embedded strings:
>>
>> char x[] = "ABC\0DEF"
^^^^^^^^^^^^^^^^^^^^^

>
> Is *what* a string or two embedded strings?

For some reason, I see two "embedded" "C strings" wrt null termination here.

> x as a whole does not contain a string, but there are 8 strings within it.

Well, I was referring to that null terminator. So I see two "C strings"
separated by an offset? Wrt using std functions that terminate on a '\0'?

I think I am misunderstanding you. Sorry... ;^o

>
>> _____________________
>> #include <stdio.h>
>>
>> int main()
>> {
>> char x[] = "ABC\0DEF";
>>
>> printf("%s\n", x);
>> printf("%s", x + 4);
>>
>> return 0;
>> }
>> _____________________
>>
>> Any undefined behavior here?
>
> No, and none in this:
>
> for (size_t i = 0; i < sizeof x; i ++) {
> printf("%s\n", x+i);
> }
>

bart <bc@freeuk.com> writes:
[...]
> In't it cheating when half the program is part of the build
> instructions?

Apparently not. If it were, the judges of the IOCCC would not have
accepted it.

The most recent rules are here:

https://www.ioccc.org/2020/rules.txt

I have not studied them to verify that the entry in question obeys them,
but the judges know what they're doing.

One of the winners of the 1988 contest was:
```
#include "/dev/tty"
```

This won a "Best Abuse of the Rules" award and resulted in a change in
the 1989 rules to forbid doing the same thing again.

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

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 2/29/2024 1:45 PM, Keith Thompson wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 2/29/2024 7:22 AM, Richard Harnden wrote:
>>>> On 29/02/2024 14:31, bart wrote:
>> [...]
>>>>> Not here:
>>>>>
>>>>>      char s[]  = "ABC";
>>>>>      char t[3] = "DEF";
>>>>>
>>>>> The "DEF" string doesn't end with a zero.
>>>> And is, therefore, not a string.
>>> [...]
>>>
>>> Right. However, is this a string or two embedded strings:
>>>
>>> char x[] = "ABC\0DEF"
> ^^^^^^^^^^^^^^^^^^^^^
>
>> Is *what* a string or two embedded strings?
>
> For some reason, I see two "embedded" "C strings" wrt null termination here.

I was asking you to clarify what you're referring to. What you posted
is a declaration, not a string. You could have been referring to the
object x, to the string literal, to subsets of either, or to something else.

>> x as a whole does not contain a string, but there are 8 strings within it.
>
> Well, I was referring to that null terminator. So I see two "C
> strings" separated by an offset? Wrt using std functions that
> terminate on a '\0'?
>
> I think I am misunderstanding you. Sorry... ;^o

I thought I explained it, but here's a more straightforward explanation.
And the term "string" is defined by 7.1.1p1, not by the behavior of
standard functions: "A *string* is a contiguous sequence of characters
terminated by and including the first null character."

At run time, the array `x` contains:
- A string of length 3 starting at index 0.
- A string of length 2 starting at index 1.
- A string of length 1 starting at index 2.
- A string of length 0 starting at index 3.
- A string of length 3 starting at index 4.
- A string of length 2 starting at index 5.
- A string of length 1 starting at index 6.
- A string of length 0 starting at index 7.

#include <stdio.h>
int main(void) {
char x[] = "ABC\0DEF";
for (size_t i = 0; i < sizeof x; i ++) {
printf("x[%zu] is a pointer to the string \"%s\"\n", i, x+i);
}
}

Output:
x[0] is a pointer to the string "ABC"
x[1] is a pointer to the string "BC"
x[2] is a pointer to the string "C"
x[3] is a pointer to the string ""
x[4] is a pointer to the string "DEF"
x[5] is a pointer to the string "EF"
x[6] is a pointer to the string "F"
x[7] is a pointer to the string ""

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

On 29/02/2024 22:05, Lawrence D'Oliveiro wrote:
> On Thu, 29 Feb 2024 08:58:40 +0100, David Brown wrote:
>
>> On 28/02/2024 21:56, Lawrence D'Oliveiro wrote:
>>>
>>> On Wed, 28 Feb 2024 12:50:10 +0100, David Brown wrote:
>>>
>>>> ... people write utilities for them in a variety of languages ...
>>>>
>>>> But it will often be more convenient to have it built into the
>>>> language and compiler.
>>>
>>> What can be built into the language can only ever be a small subset of
>>> the many and varied ways that people have incorporated data blobs into
>>> their programs.
>>
>> Of course. But that doesn't mean that a language should not include a
>> feature that makes it easy for a lot of people to get some data blobs
>> into their code.
>
> Maybe the C compiler should concentrate on compiling C code, and leave it
> to the rest of the build toolchain to deal with other data.

It is possible to be actively involved in the development of the
standards - preparing and discussing proposals, joining committees, or
at least joining mailing lists for the discussions. If you are not
doing the work and showing the interest /before/ decisions are made, you
don't get a say afterwards. It is more productive to discuss what you
can do with the features C has, than to wish it never had them.

Oh, and the reason C23 has #embed, is because people want it. It is
something C developers have asked for for many years. /You/ might not
have use of it, but that's true of lots of features of C for all
programmers - no one needs everything in the language and standard library.

On 29/02/2024 21:27, Lawrence D'Oliveiro wrote:
> On Thu, 29 Feb 2024 18:09:52 GMT, Scott Lurndal wrote:
>
>> I have an actual use case today where #embed of a (C++) std::map binary
>> object created by separate tool would be very useful. I'm planning on
>> using mmap to load it at runtime at the moment.
>
> Why not convert it to a .o file and statically link it into your program
> as part of the build process?

That's exactly what #embed will enable.

On 29/02/2024 15:34, tTh wrote:
> On 2/29/24 11:18, bart wrote:
>> Using 'strinclude' in my old C compiler, it took about 1 second to
>> build this program:
>>
>>    #include <stdio.h>
>>    #include <string.h>
>>
>>    char* s=strinclude("data");
>>
>>    int main(void) {
>>       printf("%zu\n", strlen(s));
>>   }
>
> tth@redlady:~/Desktop$ man strinclude
> No manual entry for strinclude
> tth@redlady:~/Desktop$
>

'strinclude' is an extension I made for that compiler.

#embed is the new feature of C23. Although I'm not sure how it would be
used to initialise a char* pointer. Perhaps like this:

char dummy[] {
#embed "data"
,0};
char* s = dummy;

(I've added a 0-terminator here; I don't know if #embed will take care
of that.)

My 'strinclude' produces a zero-terminated string, but it is done within
the parser rather than lexer.

On 01/03/2024 12:58, bart wrote:
> On 29/02/2024 15:34, tTh wrote:
>> On 2/29/24 11:18, bart wrote:
>>> Using 'strinclude' in my old C compiler, it took about 1 second to
>>> build this program:
>>>
>>>    #include <stdio.h>
>>>    #include <string.h>
>>>
>>>    char* s=strinclude("data");
>>>
>>>    int main(void) {
>>>       printf("%zu\n", strlen(s));
>>>   }
>>
>> tth@redlady:~/Desktop$ man strinclude
>> No manual entry for strinclude
>> tth@redlady:~/Desktop$
>>
>
> 'strinclude' is an extension I made for that compiler.
>
> #embed is the new feature of C23. Although I'm not sure how it would be
> used to initialise a char* pointer. Perhaps like this:
>
>     char dummy[]  {
>     #embed "data"
>     ,0};
>     char* s = dummy;
>
> (I've added a 0-terminator here; I don't know if #embed will take care
> of that.)

#embed very specifically does not add anything. So you would do :

const char s[] = {
#embed "data" suffix(,)
0
};

The "suffix" parameter adds a comma if "data" is not empty, and does
nothing if "data" is empty. Writing it as you did would work fine for
non-empty "data" but give the nonsensical results {,0} if "data" is
empty. (You might not care about such cases and prefer to write the
simpler version, but now you also know about "suffix".)

There is no need to have a separate character pointer variable - the
const char array can be used directly in most circumstances.

>
> My 'strinclude' produces a zero-terminated string, but it is done within
> the parser rather than lexer.

On 29/02/2024 21:36, Lawrence D'Oliveiro wrote:
> On Thu, 29 Feb 2024 16:19:45 +0100, David Brown wrote:
>
>> An array of bytes is not a "string".
>
> It is in PHP, I think also in Perl, and also in (obsolete) Python 2.
>
> And what about C string functions that take explicit lengths?

You mean: There's a danger that a function that returns a 'string', but
truncates it to n chars, might not be returning a string at all ?

On 2024-03-01, David Brown <david.brown@hesbynett.no> wrote:
> It is possible to be actively involved in the development of the
> standards - preparing and discussing proposals, joining committees, or
> at least joining mailing lists for the discussions. If you are not
> doing the work and showing the interest /before/ decisions are made, you
> don't get a say afterwards. It is more productive to discuss what you
> can do with the features C has, than to wish it never had them.

Also, if you don't join the gang that breaks windows and spray
paints walls, you don't get to say aftward which windows are broken
and what is scribbled on what wall.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 29.02.2024 23:06, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> In't it cheating when half the program is part of the build
>> instructions?

I recall from decades ago (when I looked into this contest) that they
even had a contribution that fed the whole C program into the compiler
through compiler options. (I think it even got a prize.)

"Is it cheating?" - I'd say no, since it was accepted.

Is it really about an "obfuscated C code"? - I'd say no. (But it was
anyway a curiosity.)

>
> Apparently not. If it were, the judges of the IOCCC would not have
> accepted it.
> [...]
>
> One of the winners of the 1988 contest was:
> ```
> #include "/dev/tty"

This is great! :-)

Janis

On 01/03/2024 17:55, Kaz Kylheku wrote:
> On 2024-03-01, David Brown <david.brown@hesbynett.no> wrote:
>> It is possible to be actively involved in the development of the
>> standards - preparing and discussing proposals, joining committees, or
>> at least joining mailing lists for the discussions. If you are not
>> doing the work and showing the interest /before/ decisions are made, you
>> don't get a say afterwards. It is more productive to discuss what you
>> can do with the features C has, than to wish it never had them.
>
> Also, if you don't join the gang that breaks windows and spray
> paints walls, you don't get to say aftward which windows are broken
> and what is scribbled on what wall.
>

A slightly closer version of that feeble analogy would be that you don't
get to say they should have used a different colour, or broken doors
instead of windows.

It's okay for Lawrence (or anyone else) to say that don't approve of
#embed, or don't think they will use it themselves. But like most
(probably all) features in newer C standards, it was added because
enough people wanted it for the committee and connected developers to do
the work designing and documenting the features, and testing prototypes
in practice.

There are procedures in place for people to have an influence on the
future of C. If you want to have your say, you can have it. But
waiting until a new standard version is solidified and then complaining
that you don't like the direction it is taking, is too late. Whining
about things here afterwards doesn't do anyone any good.

That's different from saying you don't like the feature, or you don't
like the way C is heading, or you won't use it yourself. And it's
different from talking about it, trying to learn how a new feature works
and how to make the best of it. Such discussions are great, and I'd
love to see more of them here in c.l.c.

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 29.02.2024 23:06, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> In't it cheating when half the program is part of the build
>>> instructions?
>
> I recall from decades ago (when I looked into this contest) that they
> even had a contribution that fed the whole C program into the compiler
> through compiler options. (I think it even got a prize.)

1990/stig.c:
```
c ```

stig.ksh provides a ksh alias that compiles it with a long "-D..."
option. (The resulting program prints a message indicating whether the
compiler supports nested /**/ comments.)

Like most Abuse of the Rules winners, it resulted in a rule change for
the following years.

https://www.ioccc.org/years.html#1990

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

On Fri, 1 Mar 2024 12:59:43 +0000, Richard Harnden wrote:

> You mean: There's a danger that a function that returns a 'string', but
> truncates it to n chars, might not be returning a string at all ?

If it’s not NUL-terminated, then it’s not a “string”, right?

On 01.03.2024 19:49, Keith Thompson wrote:
>
> Like most Abuse of the Rules winners, it resulted in a rule change for
> the following years.

Makes sense.

Janis

On 2/29/2024 2:14 PM, Keith Thompson wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 2/29/2024 1:45 PM, Keith Thompson wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>> On 2/29/2024 7:22 AM, Richard Harnden wrote:
>>>>> On 29/02/2024 14:31, bart wrote:
>>> [...]
>>>>>> Not here:
>>>>>>
>>>>>>      char s[]  = "ABC";
>>>>>>      char t[3] = "DEF";
>>>>>>
>>>>>> The "DEF" string doesn't end with a zero.
>>>>> And is, therefore, not a string.
>>>> [...]
>>>>
>>>> Right. However, is this a string or two embedded strings:
>>>>
>>>> char x[] = "ABC\0DEF"
>> ^^^^^^^^^^^^^^^^^^^^^
>>
>>> Is *what* a string or two embedded strings?
>>
>> For some reason, I see two "embedded" "C strings" wrt null termination here.
>
> I was asking you to clarify what you're referring to. What you posted
> is a declaration, not a string. You could have been referring to the
> object x, to the string literal, to subsets of either, or to something else.
>
>>> x as a whole does not contain a string, but there are 8 strings within it.
>>
>> Well, I was referring to that null terminator. So I see two "C
>> strings" separated by an offset? Wrt using std functions that
>> terminate on a '\0'?
>>
>> I think I am misunderstanding you. Sorry... ;^o
>
> I thought I explained it, but here's a more straightforward explanation.
> And the term "string" is defined by 7.1.1p1, not by the behavior of
> standard functions: "A *string* is a contiguous sequence of characters
> terminated by and including the first null character."
[...]

Ahhh yes. Sorry for glossing over that point.

On Fri, 1 Mar 2024 11:52:16 +0000, bart wrote:

> On 29/02/2024 21:27, Lawrence D'Oliveiro wrote:
>
>> On Thu, 29 Feb 2024 18:09:52 GMT, Scott Lurndal wrote:
>>
>>> I have an actual use case today where #embed of a (C++) std::map
>>> binary object created by separate tool would be very useful. I'm
>>> planning on using mmap to load it at runtime at the moment.
>>
>> Why not convert it to a .o file and statically link it into your
>> program as part of the build process?
>
> That's exactly what #embed will enable.

You can call it a toy version of objcopy
<https://manpages.debian.org/1/objcopy.1.html>.

On Thu, 29 Feb 2024 14:14:52 -0800, Keith Thompson wrote:

> "A *string* is a contiguous sequence of characters
> terminated by and including the first null character."

So how come strlen(3) does not include the null?