/dev/chat

9:07 AM

@FaheemMitha "on the shell", yes, but you're not using the shell now. See the man pages, execlp(3): "The exec() functions return only if an error has occurred. The return value is -1, and errno is set to indicate the error. All of these functions may fail and set errno for any of the errors specified for execve(2)."

hmm, I have a hard time figuring that out from the texts I find, they all say "An integer constant expression with the value 0, or such an expression cast to type void *, is called a _null pointer constant_.
If a null pointer constant is converted to a
pointer type, the resulting pointer, called a _null pointer_, is guaranteed to compare unequal to a pointer to any object or function." (it doesn't say anything about object pointers vs. function pointers.)

that's from here open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf C1x draft from April 12, 2011, I don't know if there's some more authoritative freely available source.

and anyway, like I said, glibc gives NULL defined as ((void *) 0). It would seem odd if they gave a technically wrong definition. Also I can't get at least gcc to complain about assigning that to a function pointer, but I can get it to complain about assigning a generic void * to a function pointer

10:03 AM

@ilkkachu Oh. I thought the shell and the C function would give the same error, because the shell is just calling the function. Reviewing my code now.

@MichaelHomer Thanks for the link.

11:58 AM

Just tried using @MichaelHomer's suggestion from:

Oct 17 at 19:17, by Michael Homer

sh -c 'exit 3'

This version works: execlp("sh", "sh", "-c", "exit 17", (char *)NULL);

This version doesn't: execlp("sh", "sh", "-c", "'exit 17'", (char *)NULL);

and gives the error:

> sh: 1: exit 17: not found

I'm not sure why.

Apparently the right thing is not to use the single quotes here.

if you have the shell command sh -c "exit 17", or sh -c 'exit 17', or sh -c exit\ 17, the result is that sh gets executed with the three arguments sh, -c, and exit 17 (counting sh here since you need to explicitly pass it with exec*()). The quotes there are just a shell construct, and they're needed to prevent the shell from splitting that into four arguments, but they don't remain there in what actually runs.

And the one with "exit 17" is already a single string, just in C. If you were to pass the two arguments exit and 17 separately, you'd do execlp(..., "exit", "17", ...);

@ilkkachu I see. So the backslash version, namely sh -c exit\ 17 also stops the shell from splitting up the exit 17 argument into two arguments?

12:16 PM

@FaheemMitha yes, it doesn't matter how the space is escaped or quoted, it prevents the parser from taking it as a separating the words.

@ilkkachu OK. Thank you.

I was also wondering what happens in the case of the second version to cause the error:

> sh: 1: exit 17: not found

I have been unable to reproduce this from the shell.

run "exit 17" at a shell

(or the same with single quotes, which is strictly what you're giving via the above command, not that it makes a difference)

sorry for the confusion

12:37 PM

@JeffSchaller Oh. I was trying sh -c "exit 17". Which doesn't return anything.

if you're calling sh again, then you need more quotes -- sh -c "'exit 17'", like your execlp line was

@JeffSchaller Looks like I tried that with single quotes twice. Which I suppose isn't the same thing.

sh -c  ' ' exit 17 ' '

correct, it's not the same thing

@FaheemMitha take the args script from here and play with that: mywiki.wooledge.org/WordSplitting (This isn't about word splitting as such, since that means the splitting of expanded variables. But the thing about the resulting arguments is the same.)

(or write a script that prints e.g. "$1" and "$2" in some format you like. I'd suggest running with set -x, but (in Bash) it produces output quoted as shell syntax, so then you'd need to parse that by hand again...)

Ben

1:07 PM

If I use a rolling release linux distro, will I be able to reboot less and reinstall less compared to non rolling release?

If not, how do you classify the size of each update/upgrade so that it is defined to be rolling or not rolling

You'll want to reboot for all kernel and libc security updates with either. Other updates can probably be applied without rebooting. (Except that if there's an update to X/Wayland or the desktop environment, you might need to logout and relogin which is almost the same.)

Ben

How small each update/upgrade can it be called rolling?

1:38 PM

@Ben Rolling distributions are more unstable than fixed release distributions (or whatever they are called), so not such good choices for a non-expert.

Sometimes things break and have to be fixed.

1:52 PM

@ilkkachu Any script in particular? That page has a bunch of them.

2:19 PM

@Ben Reinstall less: ideally, reinstalling should and could never be needed - I seem to recall having seen (in recent years) some distribution with no upgrade path from release n to release n_+1 (for some specific value of _n), hence requiring a complete reinstall, but those cases should be exceptions these days.

@Ben Reboot less: most likely, a rolling release will require you to reboot more often (e.g. on my Arch the kernel has been upgraded six times this month alone).

terdon

I have never reinstalled my Arch.

$ ls /etc/ -tl | tail -n1
drwxr-xr-x 4 root root     4096 May  7  2016 ca-certificates

Same here. But I wonder how hard it could have been, for instance, to upgrade it when it switched to systemd from whatever it used to have before.

@Ben "Rolling" is not about the size of updates. It means the distribution has just one release (or no releases at all, depending on how you see it).

2:46 PM

@terdon whew, almost thought you were grepping ls there!

Q: Now live: A fully responsive profile

4:56 PM

Can anyone suggest a C linter for Debian? I'm having trouble finding one.

MSE featured posts feed

25

Update As of 2021-10-21T18:05:38+00:00 this is now live across the network. If you find any issues, you can post them as answers on this question. Try to give some details about your browser and platform if that’s relevant. Thanks for all the feedback so far! Original Post We’ve been chipping awa...

Michael Homer

5:47 PM

@ilkkachu Well, from the same source, here’s 2018 WG14 minutes discussing introduction of a funcptr_t type to resolve this very issue, and here’s the proposal they’re discussing documenting the gap.

@ilkkachu GCC is free to implement extensions, that’s what implementation-defined means. In particular, POSIX requires function pointers to be the same size as void and interconvertible for dlsym to work, but C explicitly does not mandate that (because there are real systems where it’s not and can’t be the case). Portable or straight C can’t do that

8:23 PM

I looked at this a bit more, and for the case of:

execlp("lsx", "lsx", "-la", "zarko.tex", (char *)NULL);

it seems that execlp returns.

I'm not clear under what circumstances it returns, but apparently being unable to find the requested command is one of them.

Another thing I don't understand in this case is why standard error isn't printed out. On the shell it's printed out.

Example code: gist.github.com/d0579cdb26ab56a0a70fa41e68080f54

8:44 PM

@FaheemMitha I'd have thought the point about exec functions returning when they fail (assuming you don't have a program called lsx) was... settled :-)

@FaheemMitha Without knowing much on the subject, I would start from the conditions listed in the standard (man7.org/linux/man-pages/man3/execvp.3p.html#ERRORS)

(Though, of course, I'm not sure you were asking what those conditions are).