Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #89895 > unrolled thread

Re: Manipulating C code at the AST level, in C

Back to article view | Back to comp.os.linux.misc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Manipulating C code at the AST level, in C Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-14 12:26 +0100
    Re: Manipulating C code at the AST level, in C Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-08-14 13:53 +0100
      Re: Manipulating C code at the AST level, in C Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-14 21:10 +0000
    Re: Manipulating C code at the AST level, in C scott@slp53.sl.home (Scott Lurndal) - 2026-08-14 16:00 +0000
    Re: Manipulating C code at the AST level, in C c186282 <c186282@nnada.net> - 2026-08-14 23:47 -0400
      Re: Manipulating C code at the AST level, in C rbowman <bowman@montana.com> - 2026-08-15 07:20 +0000
        Re: Manipulating C code at the AST level, in C The Natural Philosopher <tnp@invalid.invalid> - 2026-08-15 11:33 +0100
        Re: Manipulating C code at the AST level, in C c186282 <c186282@nnada.net> - 2026-08-15 22:41 -0400
          Re: Manipulating C code at the AST level, in C "Carlos E. R." <robin_listas@es.invalid> - 2026-08-16 10:50 +0200
            Re: Manipulating C code at the AST level, in C rbowman <bowman@montana.com> - 2026-08-16 19:04 +0000
      Re: Manipulating C code at the AST level, in C Jim Jackson <jj@franjam.org.uk> - 2026-08-15 11:07 +0000
        Re: Manipulating C code at the AST level, in C The Natural Philosopher <tnp@invalid.invalid> - 2026-08-15 12:18 +0100
      Re: Manipulating C code at the AST level, in C Richard Kettlewell <invalid@invalid.invalid> - 2026-08-15 12:20 +0100
        Re: Manipulating C code at the AST level, in C c186282 <c186282@nnada.net> - 2026-08-16 02:09 -0400
          Re: Manipulating C code at the AST level, in C Richard Kettlewell <invalid@invalid.invalid> - 2026-08-16 09:59 +0100
            Re: Manipulating C code at the AST level, in C The Natural Philosopher <tnp@invalid.invalid> - 2026-08-16 11:42 +0100
          Re: Manipulating C code at the AST level, in C rbowman <bowman@montana.com> - 2026-08-16 19:13 +0000

#89895 — Re: Manipulating C code at the AST level, in C

(Given I'm commenting on the content of the online manual on a Linux
system, I'm adding and followingup-to comp.os.linux.misc.)

On 2026-08-11, Lawrence D’Oliveiro wrote:

> On Mon, 10 Aug 2026 17:41:30 -0300, Anton Antimo wrote:
>
>> For select (called unix-fast-select in SBCL), see sb-unix.
>
> select(2) is considered an archaic way of doing things these days,
> because of its ABI limitations. The modern way is poll()
> <https://manpages.debian.org/poll(2)> (POSIX) or even epoll()
> <https://manpages.debian.org/epoll(7)> (Linux-specific).

The online manual here (a GNU/Linux system) says:

    "poll, ppoll - wait for some event on a file descriptor"

Perhaps that should be rewritten. Reading further, it's not singular,
but that description with "*A* file descriptor" does make it sound like
poll is not a suitable replacement for select.

-- 
Nuno Silva

(Not subscribed to comp.lang.c)

[toc] | [next] | [standalone]

#89896

Nuno Silva wrote:

> The online manual here (a GNU/Linux system) says:
> 
>     "poll, ppoll - wait for some event on a file descriptor"
> 
> Perhaps that should be rewritten. Reading further, it's not singular,
> but that description with "*A* file descriptor" does make it sound like
> poll is not a suitable replacement for select.

The POSIX/SUS poll() page has:

    "poll, ppoll - input/output multiplexing"

https://pubs.opengroup.org/onlinepubs/9799919799/functions/poll.html

-- 
Geoff Clare <netnews@gclare.org.uk>

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

#89898

On Fri, 14 Aug 2026 13:53:21 +0100, Geoff Clare wrote:

> Nuno Silva wrote:
>
>> The online manual here (a GNU/Linux system) says:
>>
>>     "poll, ppoll - wait for some event on a file descriptor"
>>
>> Perhaps that should be rewritten. Reading further, it's not
>> singular, but that description with "*A* file descriptor" does make
>> it sound like poll is not a suitable replacement for select.

Oh, it most certainly is. And then some.

> The POSIX/SUS poll() page has:
>
>     "poll, ppoll - input/output multiplexing"
>
> https://pubs.opengroup.org/onlinepubs/9799919799/functions/poll.html

That is the official reference. But perhaps slightly more readable,
and with examples: <https://manpages.debian.org/poll(2)>.

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

#89897

Nuno Silva <nunojsilva@invalid.invalid> writes:
>(Given I'm commenting on the content of the online manual on a Linux
>system, I'm adding and followingup-to comp.os.linux.misc.)
>
>On 2026-08-11, Lawrence D’Oliveiro wrote:
>
>> On Mon, 10 Aug 2026 17:41:30 -0300, Anton Antimo wrote:
>>
>>> For select (called unix-fast-select in SBCL), see sb-unix.
>>
>> select(2) is considered an archaic way of doing things these days,
>> because of its ABI limitations. The modern way is poll()
>> <https://manpages.debian.org/poll(2)> (POSIX) or even epoll()
>> <https://manpages.debian.org/epoll(7)> (Linux-specific).
>
>The online manual here (a GNU/Linux system) says:
>
>    "poll, ppoll - wait for some event on a file descriptor"
>
>Perhaps that should be rewritten. Reading further, it's not singular,

Perhaps you'd be better off consulting the definitive
manual page for poll/ppoll.

https://pubs.opengroup.org/onlinepubs/9799919799/functions/ppoll.html

NAME

    poll, ppoll - input/output multiplexing

SYNOPSIS

    #include <poll.h>

    int poll(struct pollfd fds[], nfds_t nfds, int timeout);
    int ppoll(struct pollfd fds[], nfds_t nfds,
           const struct timespec *restrict timeout,
           const sigset_t *restrict sigmask);

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

#89902

On 8/14/26 07:26, Nuno Silva wrote:
> (Given I'm commenting on the content of the online manual on a Linux
> system, I'm adding and followingup-to comp.os.linux.misc.)
> 
> On 2026-08-11, Lawrence D’Oliveiro wrote:
> 
>> On Mon, 10 Aug 2026 17:41:30 -0300, Anton Antimo wrote:
>>
>>> For select (called unix-fast-select in SBCL), see sb-unix.
>>
>> select(2) is considered an archaic way of doing things these days,
>> because of its ABI limitations. The modern way is poll()
>> <https://manpages.debian.org/poll(2)> (POSIX) or even epoll()
>> <https://manpages.debian.org/epoll(7)> (Linux-specific).
> 
> The online manual here (a GNU/Linux system) says:
> 
>      "poll, ppoll - wait for some event on a file descriptor"
> 
> Perhaps that should be rewritten. Reading further, it's not singular,
> but that description with "*A* file descriptor" does make it sound like
> poll is not a suitable replacement for select.


   Polling, for this sort of thing, has to be
   fast and constant - a big CPU drag. You are
   basically WAITING for something to happen -
   which MAY or may NOT happen at any moment.

   The writers of various utils and basic system
   functions NEED to include some kind of easy
   flag or interrupt routine that other utils can
   monitor at VERY LOW CPU/Time investment.

   Coding such 'trigger indicators' is NOT difficult.

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

#89904

On Fri, 14 Aug 2026 23:47:19 -0400, c186282 wrote:

>    Polling, for this sort of thing, has to be
>    fast and constant - a big CPU drag. You are
>    basically WAITING for something to happen -
>    which MAY or may NOT happen at any moment.

I used select() rather than poll() but I'm archaic. Typically the select 
call was in the main loop. The timeout was often 1 second. If the call 
returned a ready fd you took care of business. If it timed out, then you 
did whatever housekeeping was necessary, making sure it wasn't a long 
process.

Without the select the main loop would chew up 100% of the CPU. Interrupt 
have their place but often complex ISRs are used that aren't any faster 
than polling. 

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

#89906

On 15/08/2026 08:20, rbowman wrote:
> On Fri, 14 Aug 2026 23:47:19 -0400, c186282 wrote:
> 
>>     Polling, for this sort of thing, has to be
>>     fast and constant - a big CPU drag. You are
>>     basically WAITING for something to happen -
>>     which MAY or may NOT happen at any moment.
> 
> I used select() rather than poll() but I'm archaic. Typically the select
> call was in the main loop. The timeout was often 1 second. If the call
> returned a ready fd you took care of business. If it timed out, then you
> did whatever housekeeping was necessary, making sure it wasn't a long
> process.
> 
> Without the select the main loop would chew up 100% of the CPU. Interrupt
> have their place but often complex ISRs are used that aren't any faster
> than polling.

Select probaby uses an ISR

-- 
Renewable energy: Expensive solutions that don't work to a problem that 
doesn't exist instituted by self legalising protection rackets that 
don't protect,  masquerading as public servants who don't serve the public.

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

#89916

On 8/15/26 03:20, rbowman wrote:
> On Fri, 14 Aug 2026 23:47:19 -0400, c186282 wrote:
> 
>>     Polling, for this sort of thing, has to be
>>     fast and constant - a big CPU drag. You are
>>     basically WAITING for something to happen -
>>     which MAY or may NOT happen at any moment.
> 
> I used select() rather than poll() but I'm archaic. Typically the select
> call was in the main loop. The timeout was often 1 second. If the call
> returned a ready fd you took care of business. If it timed out, then you
> did whatever housekeeping was necessary, making sure it wasn't a long
> process.
> 
> Without the select the main loop would chew up 100% of the CPU. Interrupt
> have their place but often complex ISRs are used that aren't any faster
> than polling.

   Any kind of ISR is almost always the best
   solution to the described sort of need.
   Polling is CRUDE and, as we both said, eats
   CPU like mad.

   Having done stuff with a lot of micro-controllers,
   which don't have much CPU to spare anyway, always
   did ISRs whenever possible to get data from devices.
   Depending, the ISR can push events onto a sort of
   list/stack and then you can deal with them kinda
   all at once every x-often.

   Alas, the younger set ASSUMES kinda infinite
   CPU/mem. It's poor thinking, poor discipline.
   IMHO, "Intro To Programming" should always
   start with like PICs or basic Ards. Let 'em
   learn to get the most done with the least
   resource consumption. Sometimes requires being
   CLEVER and/or learning weird quirks of the
   hardware. But we NEED clever programmers !!!

   Tax calculations, almost any idiot can code an
   app. Next mission to Mars or Titan, we need
   REALLY damned clever humans. "AI" can be kinda
   good, but it's not really "clever" and does
   not seem to anticipate weird fails.

   Still wish we'd find satellite/space-probe
   software gurus in these groups. The hyper-
   durable/redundant systems they do are nearly
   black magic. How DO you cope when cosmic rays
   may flip bits anywhere anytime ? When some
   important chip FAILS entirely ? The hardware
   folks are fantastic as well ... remote
   reload/redo/reboot of the whole system on some
   3rd-tier backup mem chip ...

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

#89931

On 2026-08-16 04:41, c186282 wrote:
>    Tax calculations, almost any idiot can code an
>    app.

I object to that. I do not want an idiot telling how much tax to pay.

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺.

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

#89944

On Sun, 16 Aug 2026 10:50:30 +0200, Carlos E. R. wrote:

> On 2026-08-16 04:41, c186282 wrote:
>>    Tax calculations, almost any idiot can code an app.
> 
> I object to that. I do not want an idiot telling how much tax to pay.

My wife volunteered to do our Federal taxes one year. She's far from an 
idiot and has more degrees than I, unfortunately not in the STEM area. I'm 
glad I checked her work. I don't know about yours but our tax forms are 
designed to keep H.R. Block in business

if (line45 < .35 * line22 && dependants > 3) {
   goto line71;
}
else if (line45 > 32196) {
   your_screwed();
}
else {
    fill_out_form_1040XYZ();
}

They don't mail out printed forms anymore but it used to be a rather thick 
booklet. 
 

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

#89907

On 2026-08-15, c186282 <c186282@nnada.net> wrote:
> On 8/14/26 07:26, Nuno Silva wrote:
>> (Given I'm commenting on the content of the online manual on a Linux
>> system, I'm adding and followingup-to comp.os.linux.misc.)
>> 
>> On 2026-08-11, Lawrence D???Oliveiro wrote:
>> 
>>> On Mon, 10 Aug 2026 17:41:30 -0300, Anton Antimo wrote:
>>>
>>>> For select (called unix-fast-select in SBCL), see sb-unix.
>>>
>>> select(2) is considered an archaic way of doing things these days,
>>> because of its ABI limitations. The modern way is poll()
>>> <https://manpages.debian.org/poll(2)> (POSIX) or even epoll()
>>> <https://manpages.debian.org/epoll(7)> (Linux-specific).
>> 
>> The online manual here (a GNU/Linux system) says:
>> 
>>      "poll, ppoll - wait for some event on a file descriptor"
>> 
>> Perhaps that should be rewritten. Reading further, it's not singular,
>> but that description with "*A* file descriptor" does make it sound like
>> poll is not a suitable replacement for select.
>
>
>    Polling, for this sort of thing, has to be
>    fast and constant - a big CPU drag. You are
>    basically WAITING for something to happen -
>    which MAY or may NOT happen at any moment.

Despite the names, these functions WAIT for events. 
Yes it could be sort of confusing.

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

#89908

On 15/08/2026 12:07, Jim Jackson wrote:
> On 2026-08-15, c186282 <c186282@nnada.net> wrote:
>> On 8/14/26 07:26, Nuno Silva wrote:
>>> (Given I'm commenting on the content of the online manual on a Linux
>>> system, I'm adding and followingup-to comp.os.linux.misc.)
>>>
>>> On 2026-08-11, Lawrence D???Oliveiro wrote:
>>>
>>>> On Mon, 10 Aug 2026 17:41:30 -0300, Anton Antimo wrote:
>>>>
>>>>> For select (called unix-fast-select in SBCL), see sb-unix.
>>>>
>>>> select(2) is considered an archaic way of doing things these days,
>>>> because of its ABI limitations. The modern way is poll()
>>>> <https://manpages.debian.org/poll(2)> (POSIX) or even epoll()
>>>> <https://manpages.debian.org/epoll(7)> (Linux-specific).
>>>
>>> The online manual here (a GNU/Linux system) says:
>>>
>>>       "poll, ppoll - wait for some event on a file descriptor"
>>>
>>> Perhaps that should be rewritten. Reading further, it's not singular,
>>> but that description with "*A* file descriptor" does make it sound like
>>> poll is not a suitable replacement for select.
>>
>>
>>     Polling, for this sort of thing, has to be
>>     fast and constant - a big CPU drag. You are
>>     basically WAITING for something to happen -
>>     which MAY or may NOT happen at any moment.
> 
> Despite the names, these functions WAIT for events.
> Yes it could be sort of confusing.
> 
Normal mechanism would be to put the calling thread into suspense, and 
trigger a resume by setting a flag from interrupt. The thread then 
'resumes' and checks to see why it was woken up.

AFAICT from a cursory glance there is no difference between select and 
poll 'under the hood'.

They just present themselves differently


-- 
Civilization exists by geological consent, subject to change without notice.
  – Will Durant

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

#89909

c186282 <c186282@nnada.net> writes:
> On 8/14/26 07:26, Nuno Silva wrote:
>> The online manual here (a GNU/Linux system) says:
>>      "poll, ppoll - wait for some event on a file descriptor"
>>
>> Perhaps that should be rewritten. Reading further, it's not singular,
>> but that description with "*A* file descriptor" does make it sound
>> like poll is not a suitable replacement for select.

https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING

>   Polling, for this sort of thing, has to be
>   fast and constant - a big CPU drag.

poll() doesn’t poll, despite the name.

>   You are basically WAITING for something to happen - which MAY or may
>   NOT happen at any moment.
>
>   The writers of various utils and basic system functions NEED to
>   include some kind of easy flag or interrupt routine that other utils
>   can monitor at VERY LOW CPU/Time investment.

Already done, several decades ago.

-- 
https://www.greenend.org.uk/rjk/

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

#89923

On 8/15/26 07:20, Richard Kettlewell wrote:
> c186282 <c186282@nnada.net> writes:
>> On 8/14/26 07:26, Nuno Silva wrote:
>>> The online manual here (a GNU/Linux system) says:
>>>       "poll, ppoll - wait for some event on a file descriptor"
>>>
>>> Perhaps that should be rewritten. Reading further, it's not singular,
>>> but that description with "*A* file descriptor" does make it sound
>>> like poll is not a suitable replacement for select.
> 
> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING
> 
>>    Polling, for this sort of thing, has to be
>>    fast and constant - a big CPU drag.
> 
> poll() doesn’t poll, despite the name.

   Then it should be re-named.

>>    You are basically WAITING for something to happen - which MAY or may
>>    NOT happen at any moment.
>>
>>    The writers of various utils and basic system functions NEED to
>>    include some kind of easy flag or interrupt routine that other utils
>>    can monitor at VERY LOW CPU/Time investment.
> 
> Already done, several decades ago.

   I know, I was there, in the middle of it.

   "Chips" were the NEW NEAT-O Things. Didn't
   need a giant refrigerated box full of of
   big boards full of discrete transistors.
   Been there, seen those. You brought a
   jacket so you could do shit in the CPU
   room. Remember a DEC unit at one place,
   a roughly 1.5 meter square box in the
   middle of the laser-leveled cold-ass
   room PACKED with discrete transistors.
   The TAPE units lined the walls. Everything
   was 'overlay code' approach, explicit or
   implied.

   They COULD run an office full of serial
   terminals though, get lots or Real Stuff
   DONE  ....

   FORTRAN and COBOL.

   DID miss the 'tube era' - 'programming' with
   jumper wires - thank the gods. Hail Woden !

   Anyway, I/O Events, they SHOULD trigger a ISR
   that, at minimum, sets a "smart flag". Other
   software can LOOK for and ACT on those flags
   or lists or stacks WHEN MOST CONVENIENT.

   I remember when CPUs were CRAP ... slow, very
   limited. This stuck with me. ALWAYS look for
   the lowest CPU/Mem equation for dealing with
   "events".

   If anyone wants to learn good programming, start
   them on micro-controllers - near ZERO resources.

   Hmmmmm ... any source for late 50s "drum drives" ?
   It'd be just COOL to make 'em work with today's
   devices !  :-)

   Knew a guy who once worked with the inventor of
   the 'disk drive'. Seems the original protos used
   a coat of pure cobalt as the magnetic medium. Not
   really ideal, but they couldn't make ferrous
   coatings smooth/flat enough at the time.

   (Hmm ... legend says that Gods still live so long
   as they're remembered, their names still spoken.
   So, did I just revive Woden ? Granny pronounced
   it very close to "Wooden")

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

#89933

c186282 <c186282@nnada.net> writes:
> Richard Kettlewell wrote:
>> c186282 <c186282@nnada.net> writes:
>>> On 8/14/26 07:26, Nuno Silva wrote:
>>>> The online manual here (a GNU/Linux system) says:
>>>>       "poll, ppoll - wait for some event on a file descriptor"
>>>>
>>>> Perhaps that should be rewritten. Reading further, it's not singular,
>>>> but that description with "*A* file descriptor" does make it sound
>>>> like poll is not a suitable replacement for select.
>> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING
>> 
>>>    Polling, for this sort of thing, has to be
>>>    fast and constant - a big CPU drag.
>> poll() doesn’t poll, despite the name.
>
>   Then it should be re-named.

Obviously that’s not happening. And what would be the point? Make life
easier for people who react to single words without reading any
documentation?

-- 
https://www.greenend.org.uk/rjk/

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

#89935

On 16/08/2026 09:59, Richard Kettlewell wrote:
> c186282 <c186282@nnada.net> writes:
poll() doesn’t poll, despite the name.
>>
>>    Then it should be re-named.
> 
> Obviously that’s not happening. And what would be the point? Make life
> easier for people who react to single words without reading any
> documentation?
> 
Of course. Otherwise they might elect Trump as a president...

-- 
The difference bweteen a psychopath and a saint is that the psychpoath 
takes what he can and gives only what he must, but the saint gives 
everything he can and takes only what he needs.

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

#89945

On Sun, 16 Aug 2026 02:09:57 -0400, c186282 wrote:

>  You brought a
>    jacket so you could do shit in the CPU room.

At RPI the shrine where the 360/30 lived was the only place on campus with 
A/C. Not a bad thing on those days when the humidity in the Hudson Valley 
hits 99.9%.

The last place I worked was a converted mill building. Rather nice 
architecturally but every HVAC company in town had taken a shot at it with 
limited success. Programming wore flannel shirts in August and it wasn't a 
style thing. Portable electric heaters appeared to the consternation of 
the maintenance people.

Conversely, I leaned toward short sleeved shirts in December. The poor 
bastards on the 2nd floor were on the opposite schedule.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web