On 2/17/2023 9:16 AM, Simon Clubley wrote:
> On 2023-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> strcspn will stop when it reach the terminating null byte.
>>
>
> Are you sure about that ?
>
> https://linux.die.net/man/3/strcspn
>
> There's no mention of stopping at a null and no mention of what the
> return value is when the byte is not found within the string if it
> were to stop at a terminating null.

Then either the Linux manpage is deficient or the routine is broken.

From a BSD man:

The strcspn() function spans the initial part of the nul-terminated
string s as long as the characters from s do not occur in string
charset (it spans the complement of charset).

Or we have a problem of conflicting standards. :-)

bill

On 2/17/2023 9:45 AM, Slo wrote:
> Me: But fgets() is not guaranteed to return a newline character. Can you improve the code?
> ==========================
> You're correct that fgets() may not return the newline character if the
> input buffer is filled before encountering a newline. Here's an updated
> version of the code that handles this case:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <time.h>
> #include <string.h>
>
> int get_wattage(char *sys) {
> return (rand() % 20) * 50 + 200;
> }
>
> int main() {
> srand(time(NULL));
> char sys1[256], sys2[256];
> int watt1, watt2;
>
> printf("Utility to check power supply compatibility.\n");
> printf("Enter name of system #1: ");
> if (fgets(sys1, 256, stdin) == NULL) {
> perror("fgets failed");
> exit(1);
> }
> sys1[strcspn(sys1, "\n")] = '\0';
> if (sys1[0] == '\0') {
> fprintf(stderr, "Invalid input: system name cannot be empty\n");
> exit(1);
> }
> printf("Enter name of system #2: ");
> if (fgets(sys2, 256, stdin) == NULL) {
> perror("fgets failed");
> exit(1);
> }
> sys2[strcspn(sys2, "\n")] = '\0';
> if (sys2[0] == '\0') {
> fprintf(stderr, "Invalid input: system name cannot be empty\n");
> exit(1);
> }
> watt1 = get_wattage(sys1);
> watt2 = get_wattage(sys2);
>
> if (watt1 == watt2) {
> printf("%s and %s can use the same power supply (%d watt)\n", sys1, sys2, watt1);
> } else {
> printf("%s and %s cannot use the same power supply as they use %d and %d watt\n", sys1, sys2, watt1, watt2);
> }
> return 0;
> }
> ==========================
>

And people are already talking about trusting the code written by
the robot. :-) :-) :-)

bill

On 2023-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 2/17/2023 9:16 AM, Simon Clubley wrote:
>> On 2023-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>
>>> strcspn will stop when it reach the terminating null byte.
>>
>> Are you sure about that ?
>
> Yes.
>
>> https://linux.die.net/man/3/strcspn
>>
>> There's no mention of stopping at a null and no mention of what the
>> return value is when the byte is not found within the string if it
>> were to stop at a terminating null.
>
> "The strcspn() function returns the number of bytes in the initial
> segment of s which are not in the string reject."
>
> strcspn("abc\n", "\n") will return 3.
>
> strcspn("abc", "\n") will also return 3.
>
> That is what it says.
>

Then in that case I was wrong and I withdraw the original comment.

However, that man page is extremely misleading because when a routine
is setup to report that it didn't find something, it usually tells you
how it does that in the "RETURN VALUE" section of the documentation.

The version that Bill posted from BSD is better if not completely clear.

I had a look around to see if it was just me and it turns out it isn't:

https://stackoverflow.com/questions/32390478/what-is-the-return-value-of-strcspn-when-str1-does-not-contain-str2

The cplusplus.com reference pointed to there is far better than what is
in the man page.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2/17/2023 1:27 PM, Simon Clubley wrote:
> On 2023-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/17/2023 9:16 AM, Simon Clubley wrote:
>>> On 2023-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>
>>>> strcspn will stop when it reach the terminating null byte.
>>>
>>> Are you sure about that ?
>>
>> Yes.
>>
>>> https://linux.die.net/man/3/strcspn
>>>
>>> There's no mention of stopping at a null and no mention of what the
>>> return value is when the byte is not found within the string if it
>>> were to stop at a terminating null.
>>
>> "The strcspn() function returns the number of bytes in the initial
>> segment of s which are not in the string reject."
>>
>> strcspn("abc\n", "\n") will return 3.
>>
>> strcspn("abc", "\n") will also return 3.
>>
>> That is what it says.
>
> Then in that case I was wrong and I withdraw the original comment.
>
> However, that man page is extremely misleading because when a routine
> is setup to report that it didn't find something, it usually tells you
> how it does that in the "RETURN VALUE" section of the documentation.

The man page explains what it is returning.

In both examples above it detect 3 bytes in the start of s that
are not in reject, so it returns 3.

The "didn't find case" is not really a special case for
this function.

Arne

On Fri, 2023-02-17 at 03:58 -0800, Slo wrote:
>    fgets(sys1, 256, stdin);
>    fgets(sys2, 256, stdin);

That's disgusting!! :-D
--
Tactical Nuclear Kittens

> >
> Yep.
>
> The ChatGPT answer was just wrong.
>
> I cannot provide any artificial intelligence, but
> here is something (I intended to post this earlier
> in this thread):
>
> $ run ArtificialStupidity
> Utility to check power supply compatibility.
> Enter name of system #1: 500au
> Enter name of system #2: XP1000
> 500au and XP1000 cannot use the same power supply as they use 200 and
> 850 watt

When will netnews ever gain the ability to handle unicode chars?!
There's a fair few emoiji I'd like to insert here (laughing crying face
for instance)
--
Tactical Nuclear Kittens

On 2023-02-17 21:56:32 +0000, Single Stage to Orbit said:

> When will netnews ever gain the ability to handle unicode chars?!

🤷🏼

> There's a fair few emoiji I'd like to insert here (laughing crying face
> for instance)

😂

--
Pure Personal Opinion | HoffmanLabs LLC

On Fri, 2023-02-17 at 22:03 -0500, Stephen Hoffman wrote:
> > When will netnews ever gain the ability to handle unicode chars?!
>
> 🤷🏼
>
> > There's a fair few emoiji I'd like to insert here (laughing crying
> > face
> > for instance)
>
> 😂

Hmm, looks like my news client can't handle it then. 🤬
--
Tactical Nuclear Kittens

On 2023-02-17 14:20, Simon Clubley wrote:
> On 2023-02-17, Slo <slovuj@gmail.com> wrote:
>> Sorry Arne, I don't trust your coding skills and an ancient language :-)
>
> That ancient language is more secure than C. :-)
>
>> Me: Convert this code to C
>> ============================
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <string.h>
>> #include <time.h>
>> int get_wattage(char *sys) {
>> return (rand() % 20) * 50 + 200;
>> }
>> int main() {
>> char sys1[256], sys2[256];
>> int watt1, watt2;
>> srand(time(NULL));
>> printf("Utility to check power supply compatibility.\n");
>> printf("Enter name of system #1: ");
>> fgets(sys1, 256, stdin);
>> printf("Enter name of system #2: ");
>> fgets(sys2, 256, stdin);
>> sys1[strcspn(sys1, "\n")] = '\0';
>> sys2[strcspn(sys2, "\n")] = '\0';
>
> OUCH! OUCH! OUCH!!!!!
>
> fgets() is not guaranteed to return a newline character.

True. If you have an eof, you (obviously) don't have a newline, nor do
you get it if there are "too many" characters input.

> Here's an online man page that confirms this:
>
> https://linux.die.net/man/3/fgets
>
> I hope people using this technology with "real" code understand and
> recognise this kind of thing...

Well, the code was actually "safe". It just replaced the first newline
with a NUL, if found. Otherwise it does nothing.
So I don't really see what point you were trying to make here.

Johnny

On 2023-02-17 14:55, Simon Clubley wrote:
> On 2023-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/17/2023 8:20 AM, Simon Clubley wrote:
>>> On 2023-02-17, Slo <slovuj@gmail.com> wrote:
>>>> Sorry Arne, I don't trust your coding skills and an ancient language :-)
>>>
>>> That ancient language is more secure than C. :-)
>>>
>>>> Me: Convert this code to C
>>>> ============================
>>>> #include <stdio.h>
>>>> #include <stdlib.h>
>>>> #include <string.h>
>>>> #include <time.h>
>>>> int get_wattage(char *sys) {
>>>> return (rand() % 20) * 50 + 200;
>>>> }
>>>> int main() {
>>>> char sys1[256], sys2[256];
>>>> int watt1, watt2;
>>>> srand(time(NULL));
>>>> printf("Utility to check power supply compatibility.\n");
>>>> printf("Enter name of system #1: ");
>>>> fgets(sys1, 256, stdin);
>>>> printf("Enter name of system #2: ");
>>>> fgets(sys2, 256, stdin);
>>>> sys1[strcspn(sys1, "\n")] = '\0';
>>>> sys2[strcspn(sys2, "\n")] = '\0';
>>>
>>> OUCH! OUCH! OUCH!!!!!
>>>
>>> fgets() is not guaranteed to return a newline character.
>>
>> And?
>>
>
> Take a closer look Arne.
>
> That code will continue searching memory for a byte with the value of
> a newline character and will then modify the first such byte it finds.
>
> In other words, an out of bounds write vulnerability that may be
> exploitable in some circumstances when the code is part of a larger
> program.
>
> Even worse, the generated code _appears_ to work ok for normal inputs.

No. You are incorrect. fgets() will put into the buffer up to n-1
characters, and *always* put a NUL in at the end.
strcspn() will search the string for a specific character, and return
the index for that character if found, or the index to the NUL character
that terminates the string, if character is not found. It will never
search beyond the string read by fgets().

Johnny

On 2023-02-17 15:16, Simon Clubley wrote:
> On 2023-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> strcspn will stop when it reach the terminating null byte.
>>
>
> Are you sure about that ?
>
> https://linux.die.net/man/3/strcspn
>
> There's no mention of stopping at a null and no mention of what the
> return value is when the byte is not found within the string if it
> were to stop at a terminating null.

Quoting the man-page I have locally:

The strcspn() function spans the initial part of the null-terminated
string s as long as the characters from s do not occur in the null-
terminated string charset (it spans the complement of charset).
In other
words, it computes the string array index of the first character of s
which is also in charset, else the index of the first null character.

Johnny

On 2023-02-20, Johnny Billquist <bqt@softjar.se> wrote:
> On 2023-02-17 15:16, Simon Clubley wrote:
>> On 2023-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>
>>> strcspn will stop when it reach the terminating null byte.
>>>
>>
>> Are you sure about that ?
>>
>> https://linux.die.net/man/3/strcspn
>>
>> There's no mention of stopping at a null and no mention of what the
>> return value is when the byte is not found within the string if it
>> were to stop at a terminating null.
>
> Quoting the man-page I have locally:
>
> The strcspn() function spans the initial part of the null-terminated
> string s as long as the characters from s do not occur in the null-
> terminated string charset (it spans the complement of charset).
> In other
> words, it computes the string array index of the first character of s
> which is also in charset, else the index of the first null character.
>
>

BSD ?

That's what the Linux version should say. :-(

The way the Linux version is written, it came across as another gets()
style function, and given that someone at some time thought it was a
good idea to add gets() to the C RTL...

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2/20/2023 5:09 AM, Johnny Billquist wrote:
> On 2023-02-17 15:16, Simon Clubley wrote:
>> On 2023-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>
>>> strcspn will stop when it reach the terminating null byte.
>>>
>>
>> Are you sure about that ?
>>
>> https://linux.die.net/man/3/strcspn
>>
>> There's no mention of stopping at a null and no mention of what the
>> return value is when the byte is not found within the string if it
>> were to stop at a terminating null.
>
> Quoting the man-page I have locally:
>
>      The strcspn() function spans the initial part of the null-terminated
>      string s as long as the characters from s do not occur in the null-
>      terminated string charset (it spans the complement of charset). In
> other
>      words, it computes the string array index of the first character of s
>      which is also in charset, else the index of the first null character.
>

Is yours from Linux? Seems the Linux and BSD man pages are quite
different. Have to wonder if this is a documentation problem or
if Linux has a broken implementation of strcspn().

bill

On 2/20/2023 8:49 AM, bill wrote:
> On 2/20/2023 5:09 AM, Johnny Billquist wrote:
>> On 2023-02-17 15:16, Simon Clubley wrote:
>>> On 2023-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> strcspn will stop when it reach the terminating null byte.
>>>
>>> Are you sure about that ?
>>>
>>> https://linux.die.net/man/3/strcspn
>>>
>>> There's no mention of stopping at a null and no mention of what the
>>> return value is when the byte is not found within the string if it
>>> were to stop at a terminating null.
>>
>> Quoting the man-page I have locally:
>>
>>       The strcspn() function spans the initial part of the
>> null-terminated
>>       string s as long as the characters from s do not occur in the null-
>>       terminated string charset (it spans the complement of charset).
>> In other
>>       words, it computes the string array index of the first character
>> of s
>>       which is also in charset, else the index of the first null
>> character.
>
> Is yours from Linux?  Seems the Linux and BSD man pages are quite
> different.  Have to wonder if this is a documentation problem or
> if Linux has a broken implementation of strcspn().

Strictly speaking Linux does not have strcspn - the
C library has.

But glibc strcspn works exactly as it should.

https://github.com/zerovm/glibc/blob/master/string/strcspn.c

Actually I think the code is more readable than
the BSD implementation:

https://android.googlesource.com/platform/bionic/+/ics-mr0/libc/string/strcspn.c

YMMV

Disclaimer: neither of the links are master for glibc or OpenBSD
source code, but I assume the comments about origin are true.

Arne

In article <k5hc43Ftd0kU6@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:
>On 2/20/2023 5:09 AM, Johnny Billquist wrote:
>> On 2023-02-17 15:16, Simon Clubley wrote:
>>> On 2023-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>
>>>> strcspn will stop when it reach the terminating null byte.
>>>>
>>>
>>> Are you sure about that ?
>>>
>>> https://linux.die.net/man/3/strcspn
>>>
>>> There's no mention of stopping at a null and no mention of what the
>>> return value is when the byte is not found within the string if it
>>> were to stop at a terminating null.
>>
>> Quoting the man-page I have locally:
>>
>> The strcspn() function spans the initial part of the null-terminated
>> string s as long as the characters from s do not occur in the null-
>> terminated string charset (it spans the complement of charset). In
>> other words, it computes the string array index of the first character
>> of s which is also in charset, else the index of the first null character.
>
>Is yours from Linux? Seems the Linux and BSD man pages are quite
>different. Have to wonder if this is a documentation problem or
>if Linux has a broken implementation of strcspn().

Broken in what way? This seems entirely consistent with the
definition in the BSD man page. The OpenBSD 7.2 man page even
gives an example surprisingly close to what was posted earlier:

--->BEGIN<---
EXAMPLES
[snip...]

The following removes the first (if any) newline character from string
line. This is useful for trimming the newline after a fgets(3) call.

char line[BUFSIZ];

if (fgets(line, sizeof(line), fp) != NULL)
line[strcspn(line, "\n")] = '\0';
--->END<---

From the C11 standard, section 7.24.5.3:

"size_t strcspn(const char *s1, const char *s2);

The strcspn function computes the length of the maximum
initial segment of the string pointed to by s1 which
consists entirely of characters not from the string
pointed to by s2.

Returns
The strcspn function returns the length of the segment."

Note the use of the term "string", which is defined as used here
in section 7.1.1:

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

The idea that `strcspn` would return the index of the
terminating NUL character for its first argument, should the
string it points to not contain any non-NUL characters from
the second argument, follows from these two definitions.
Since both strings are considered to contain their terminating
NUL characters, then that would necessarily match if nothing
else did.

- Dan C.

On 2/20/2023 5:08 AM, Johnny Billquist wrote:
> On 2023-02-17 14:55, Simon Clubley wrote:
>> On 2023-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 2/17/2023 8:20 AM, Simon Clubley wrote:
>>>> On 2023-02-17, Slo <slovuj@gmail.com> wrote:
>>>>>       fgets(sys1, 256, stdin);
>>>>>       printf("Enter name of system #2: ");
>>>>>       fgets(sys2, 256, stdin);
>>>>>       sys1[strcspn(sys1, "\n")] = '\0';
>>>>>       sys2[strcspn(sys2, "\n")] = '\0';
>>>>
>>>> OUCH! OUCH! OUCH!!!!!
>>>>
>>>> fgets() is not guaranteed to return a newline character.

>> That code will continue searching memory for a byte with the value of
>> a newline character and will then modify the first such byte it finds.
>>
>> In other words, an out of bounds write vulnerability that may be
>> exploitable in some circumstances when the code is part of a larger
>> program.
>>
>> Even worse, the generated code _appears_ to work ok for normal inputs.
>
> No. You are incorrect. fgets() will put into the buffer up to n-1
> characters, and *always* put a NUL in at the end.
> strcspn() will search the string for a specific character, and return
> the index for that character if found, or the index to the NUL character
> that terminates the string, if character is not found. It will never
> search beyond the string read by fgets().

As I think everybody has agreed by now then the code
is safe.

I still stand by my original assessment that I would not
have used strcspn for this. It seems weird to me to
search through the entire string in a way that can handle
multiple stop characters when one knows that there is
only one stop character and really are only interested
in the last char in the string.

Also note that even though in all practical cases
the Pascal and C code will act identical, then it is
possible to create a case where they do not on VMS.

$ type p.pas
program p(input,output);

type
pstr = varying [255] of char;

var
line : pstr;

begin
readln(line);
writeln(line.length:1);
end.
$ pas p
$ link p
$ type c.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main()
{ char line[256];
fgets(line, 256, stdin);
line[strcspn(line, "\n")] = '\0';
printf("%d\n", strlen(line));
return 0;
} $ cc c
$ link c
$ run p
ABC
3 $
$ run c
ABC
3 $
$ define/user sys$input z.txt
$ run p
7 $ define/user sys$input z.txt
$ run c
3

The VMS knowledgeable has of course already guessed
the reason - the file z.txt is RFM:VAR and contains
a line with newline in.

I do not blame ChatGPT for not thinking about that. This
is a very special case.

Arne

On 2023-02-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> As I think everybody has agreed by now then the code
> is safe.
>

Yes. :-)

> I still stand by my original assessment that I would not
> have used strcspn for this. It seems weird to me to
> search through the entire string in a way that can handle
> multiple stop characters when one knows that there is
> only one stop character and really are only interested
> in the last char in the string.
>

This is exactly how I normally do it - look at the last character
only and strip that if needed.

Of course, strlen() still has to search through the string before
it knows the length of it, so you don't save as much time as you
might expect.

>
> I do not blame ChatGPT for not thinking about that. This
> is a very special case.
>

ChatGPT not thinking about some things is how some people have been
able to trick it into doing certain things. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2/21/2023 8:25 AM, Simon Clubley wrote:
> On 2023-02-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> I still stand by my original assessment that I would not
>> have used strcspn for this. It seems weird to me to
>> search through the entire string in a way that can handle
>> multiple stop characters when one knows that there is
>> only one stop character and really are only interested
>> in the last char in the string.
>>
>
> This is exactly how I normally do it - look at the last character
> only and strip that if needed.
>
> Of course, strlen() still has to search through the string before
> it knows the length of it, so you don't save as much time as you
> might expect.

Yes - strlen will involve some sort of loop.

But strcspn will involve a loop inside a loop.
Although the loop over the reject set will
be very short in this case.

glibc use while with strchr inside.

BSD use for with a do while inside.

(links posted previously)

Arne

On 2023-02-20 14:09, Simon Clubley wrote:
> On 2023-02-20, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-02-17 15:16, Simon Clubley wrote:
>>> On 2023-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>
>>>> strcspn will stop when it reach the terminating null byte.
>>>>
>>>
>>> Are you sure about that ?
>>>
>>> https://linux.die.net/man/3/strcspn
>>>
>>> There's no mention of stopping at a null and no mention of what the
>>> return value is when the byte is not found within the string if it
>>> were to stop at a terminating null.
>>
>> Quoting the man-page I have locally:
>>
>> The strcspn() function spans the initial part of the null-terminated
>> string s as long as the characters from s do not occur in the null-
>> terminated string charset (it spans the complement of charset).
>> In other
>> words, it computes the string array index of the first character of s
>> which is also in charset, else the index of the first null character.
>>
>>
>
> BSD ?

Sortof. MacOS. BSD derivate in other words.
Checked NetBSD right now. A bit little different wording, but better
than Linux still.

Johnny