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

Groups > comp.lang.lisp > #61313

Re: Malicious Computer Architecture

Show all headers | View raw

On 07/08/2026 6:01 AM, Aidan Kehoe wrote:
> 
>   Ar an cúigiú lá de mí Lúnasa, scríobh Johann Oskarsson:
> 
>   > On 04/08/2026 2:51 AM, Aidan Kehoe wrote:
>   >
>   > Hello Aidan,
>   >
>   > We haven't spoken for a long time, and I guess we're moving in different
>   > social circles now.
> 
> I spent 2012-present debugging people, and until 2021ish without the time away
> from that to maintain a social circle or do any XEmacs work. My social circle
> just shrank!
> 
>   > You will find it amusing that my patch to the FreeBSD kernel, the one
>   > that kind of tunes the TCP/IP stack, is presumably used by Whatsapp as
>   > well.
>   >
>   > At least, that's the rumor I heard; I wouldn't know the truth as I don't
>   > work for Whatsapp.  I thought only 5ch and Netflix had sites large
>   > enough to make use of it.  Well, sites both large enough, and hosted on
>   > FreeBSD.
>   >
>   > I promised myself to look into it later, and if I'm right -- at least,
>   > that my patch is still there and all -- I'll let you know.
> 
> Good.
> 
>   > It's always fun to know that whenever someone streams from Netflix, the
>   > TCP/IP patch I applied is being used; though I cannot say that it
>   > streams through my code; it wasn't that kind of patch.
>   >
>   > And I didn't, and don't work for Netflix either.
>   >
>   > I hope you're also leaving trails of patches in various operating
>   > systems that everyone on the planet, more or less, makes use of.
> 
> There’s enough to do with XEmacs plus running a business plus a three year old
> daughter plus a fiancée, that I don’t anticipate any OS patches from me this
> decade. Still, I save lives, and more importantly, prevent large strokes.

Welcome to the happy family life.  I wish you all the success with it!

> 
>   > >   Ar an triú lá de mí Lúnasa, scríobh Johann Oskarsson:
>   > >
>   > >   > On 03/08/2026 6:28 PM, David Brown wrote:
>   > >   > > On 03/08/2026 11:41, Richard Harnden wrote:
>   > >   > >> On 03/08/2026 09:16, David Brown wrote:
>   > >   > >
>   > >   > >>> On most targets, function pointers are the same size as void*
>   > >   > >>> pointers. But there are exceptions, with some small
>   > >   > >>> microcontrollers and DSPs having different kinds of pointers with
>   > >   > >>> different sizes, depending on the memory space involved.  I have
>   > >   > >>> yet to see a situation where there was any reason for storing a
>   > >   > >>> function address in a "void*" rather than a more appropriate
>   > >   > >>> typedef, such as :
>   > >   > >>>
>   > >   > >>>      typedef void (*FVoid)(void);
>   > >   > >>
>   > >   > >> dlsym requires that pointer-to-function is compatible with a void*
>   > >   > >
>   > >   > > As I say, I have yet to see a situation where using void* for
>   > >   > > function pointers was more appropriate than using a function pointer
>   > >   > > type.  If the OS system calls or standard OS libraries makes it a
>   > >   > > requirement that function pointers are converted to or from void*
>   > >   > > for some calls, then of course you need to follow those requirements
>   > >   > > - it's the people who designed the interfaces that made questionable
>   > >   > > design choices.
>   > >   >
>   > >   > Nope, you're wrong.  You're dead wrong.  The world isn't built on C,
>   > >   > even though here in comp.lang.c we like to pretend it is.
>   > >
>   > > The habit when I read comp.lang.c it was to assert that standard C was
>   > > all that was worth discussing (yes, yes, it’s phrased as standard C is on
>   > > topic, everything else isn’t; but there wasn’t the activity in the
>   > > architecture-specific groups for them to be helpful when I was reading
>   > > it). This is even more ridiculous; almost all the C infrastructure out
>   > > there relies on what is undefined behaviour by the letter of the
>   > > standard. But it’s still C, and it’s worth understanding and worth
>   > > writing.
>   >
>   > Yes, I remember that. I believe I came across a FAQ, probably comp.os.
>   > msdos.programmer, that said because comp.lang.c was full of standard
>   > thumping trolls, a lot of regular programming, even Win32 got discussed
>   > there. Yes, I'll quote.
>   >
>   >    > Why does the  newsgroup seem to  be so C-oriented sometimes?
>   >    > There   are   two    reasons.    First,  comp.lang.c     and
>   >    > comp.lang.pascal     have       evolved     in     different
>   >    > directions.  Comp.lang.pascal   has split  into  discussions
>   >    > about individual Pascal compilers.  comp.lang.pascal.borland
>   >    > welcomes discussion specific to  Turbo Pascal, and the other
>   >    > new groups likewise.  Turbo  Pascal programmers tend to find
>   >    > DOS questions  welcomed in comp.lang.pascal.borland, so that
>   >    > comp.os.msdos.programmer gets  less   of the "DOS  in  Turbo
>   >    > Pascal" traffic.  On the other  hand, comp.lang.c has stayed
>   >    > closer   to   talking only   about    the C   language,  and
>   >    > vendor-specific  or  operating-system-specific questions are
>   >    > not welcome.  This tends to push  questions about disks, DOS
>   >    > file  structure,  video,   the   keyboard,  TSRs,  etc.   to
>   >    > comp.os.msdos.programmer  even    when those   programs  are
>   >    > written in C.
>   >
>   > So my take on it, is that the standard thumping trolls in comp.lang.c were
>   > already a problem in the 90s. They just didn't know it, didn't care, and
>   > nobody challenged them about it. Until now.
> 
> Most of my comp.lang.c was the turn of the millennium. I don’t have the
> desire or spare time at the moment to read more newsgroups, and I’m happy with
> my command of C.


I've only increased my knowledge of C over the past few years.  And
since I also want to teach it -- and I've done a stint of both paid
and unpaid tutorship of it -- I've amassed a decent library of beginners
books, in addition to the more advanced topics.

There are still nooks and crannies I've questioned recently, and I
believe some of my experiments warrant yet another beginners book.

We'll just have to see if I'll write one, as I'm also not in a hurry
about that.

> 
>   > I am challenging their rule.  And they can whine, and they can bluster,
>   > but nobody cares about their mistaken sense of prestige and power.
>   >
>   > They claim my cross posting is annoying.  As far as I'm aware, I'm
>   > basically screaming into the void with my cross posts, because there
>   > isn't enough traffic in the other groups to warrant complaints about it.
> 
> Fight on! Alternatively put the time into XEmacs (or packages) work, which is,
> a better use of your time. (From my perspective, and probably in the grand
> scheme of things; neither of is likely to make any difference to comp.lang.c.)

XEmacs wasn't on my horizon until I started to write this reply.  I'm
not sure how I can be immediately useful, but I'll do my best to at
least help out with the little tasks.  See you on the XEmacs devel
list about more of that, and you'll know when I've started to read
it again.  I'll reply to something.

> 
>   > > Oh well, thank you the autoconf maintainers, thank you the cmake
>   > > maintainers, shame about the difficulty with cross-compiling.
>   >
>   > On that subject, I have to agree. I've largely given up on both for my own
>   > projects. The problems with these tools isn't when they work, it's when they
>   > don't. It can be a nightmare to get to the first build on a platform where
>   > the build system doesn't work.
> 
> Well, it’s just one more platform to learn. I would love to move XEmacs to
> cmake, given it would unify the POSIX and Windows build systems, but it would
> be a huge investment of time to port it over, because I know autoconf but I
> don’t know cmake.


Sometimes it's better to /boot strap/ the code, and just compile things
by hand for the first time.  I've done that for some projects, but
others are harder to figure out.  I'll just point to my recent effort to
hand build the Korn shell in comp.unix.shell; which I'm sure you won't
read, having a full life and all.

> 
>   > I currently believe both tools make porting to a /different enough platform/
>   > basically impossible. And that's based on hard earned experience.
> 
> My understanding is that cmake just requires a C compiler, no shell, no other
> dependencies, so it should manage a different enough platform that has a C
> compiler without problems. This is its attraction over autoconf, which
> requires /bin/sh at least, and pragmatically more of POSIX.

Way back when, when cmake was new, they didn't support cross compiling.
And that made me write it off.  Since then, it's become more complex,
and I'm not sure it's well suited to my own projects.

At work, I just use what they use there.

> 
>   > >   > Several language environments allow function generation on the fly,
>   > >   > these functions need to be garbage collected. Common Lisp is an
>   > >   > example, therefore comp.lang.lisp is added to this discussion.
>   > >   >
>   > >   > I've also added comp.theory so Mild Shock can comment.
>   > >   >
>   > >   > You will have to go out of your way to make a computer architecture
>   > >   > incompatible with garbage collected and heap allocated binary code,
>   > >   > something I've been told SBCL does internally [1] to create an archi-
>   > >   > tecture that has different
>   > >
>   > > I haven’t gone into the weeds of the GNU Emacs native-compiled function
>   > > implementation, but it has to be doing something similar. The functions
>   > > are not in the data segment, they’re not in BSS, they’re not on the
>   > > stack; that leaves the heap.
>   >
>   > And not to mention the operating system interfaces.  I'll name mmap(),
>   > and Win32 has its equivalent, and while I'm not sure, OpenVMS might be
>   > different too.
>   >
>   > All of them return the equivalent of void *. So what are the programmers of
>   > the JVM, CLR, and other virtual machines to do? They'll have to rely on
>   > this "undefined behaviour."
> 
> Well, they have to port to the various platforms, that’s all. And hope the
> platform defines the behaviour.
>   > >
>   > >   > *  sizeof ( void * ), and
>   > >   > *  sizeof ( void (*)( void ) ),
>   > >   >
>   > >   > and when you do that, I'll just claim you're making a /malicious
>   > >   > computer architecture/ and refuse to use it.
>   > >
>   > > Note that GCC on AMD64 produces function pointers that are one-byte
>   > > aligned, which to me is a similar philosophy. There cannot be any
>   > > performance advantage to that.
>   >
>   > Can you please expand on that?  I'm not sure what you mean, and I hope
>   > it doesn't create function pointers at strictly odd addresses, because
>   > that's what it sounds like to me.
> 
> https://lidell.nu/xemacs-buildbot/#/builders/14/builds/690 throws an assertion
> failure because I was storing a function pointer into a Lisp fixnum, which has
> 63 bits of precision. The least significant bit of the function pointer was
> set.
> 

I hope you figure it out.  Right now, I have n+1 projects cooking, and
I'm not in a hurry to help with XEmacs.


Best of luck with your new life!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

Back to comp.lang.lisp | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 19:23 +0800
  Re: Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-08-03 14:29 +0000
    Re: Malicious Computer Architecture Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-03 14:26 -0300
  Johnny Depp prevention [Windows 11 etc...] (Was: Malicious Computer Architecture) Mild Shock <janburse@fastmail.fm> - 2026-08-03 18:10 +0200
    But how can you deploy. when its ROM? (Was: Johnny Depp prevention [Windows 11 etc...]) Mild Shock <janburse@fastmail.fm> - 2026-08-03 18:15 +0200
      GPU Elasticity: Collective Communications Libraries (Was: But how can you deploy. when its ROM?) Mild Shock <janburse@fastmail.fm> - 2026-08-07 14:37 +0200
        What are Flits and Phits? [Network on a Chip] (Re: GPU Elasticity: Collective Communications Libraries) Mild Shock <janburse@fastmail.fm> - 2026-08-07 18:07 +0200
          Cristallina: Thank you for the Beam (Re: What are Flits and Phits? [Network on a Chip]) Mild Shock <janburse@fastmail.fm> - 2026-08-09 21:22 +0200
            Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Mild Shock <janburse@fastmail.fm> - 2026-08-18 16:26 +0200
              How to shoot yourself in the foot (Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Mild Shock <janburse@fastmail.fm> - 2026-08-18 16:50 +0200
                Re: How to shoot yourself in the foot (Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 03:24 +0800
              Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 03:21 +0800
                Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Aidan Kehoe <kehoea@parhasard.net> - 2026-08-18 21:13 +0100
                Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-18 22:49 +0000
                Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 08:32 +0800
                Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Anthk GM <anthk@disroot.org> - 2026-09-15 17:10 +0000
                Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] scott@slp53.sl.home (Scott Lurndal) - 2026-09-15 18:08 +0000
                You hear some noises in the distance (Was: Loderunner Enemy AI better than SWI-Prolog?) Mild Shock <janburse@fastmail.fm> - 2026-09-15 20:21 +0200
                Re: You hear some noises in the distance (Was: Loderunner Enemy AI better than SWI-Prolog?) scott@slp53.sl.home (Scott Lurndal) - 2026-09-15 20:05 +0000
                Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] George Neuner <gneuner2@comcast.net> - 2026-08-21 02:08 -0400
                Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-21 15:25 +0800
                Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] George Neuner <gneuner2@comcast.net> - 2026-08-21 16:28 -0400
                Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 08:27 +0800
              William A. Howard solved all his 99 problems (Re: Loderunner Enemy AI better than SWI-Prolog?) Mild Shock <janburse@fastmail.fm> - 2026-08-23 01:48 +0200
          The Mac Neo is a Budget Monster [GPU Channels] (Re: What are Flits and Phits? [Network on a Chip]) Mild Shock <janburse@fastmail.fm> - 2026-08-11 16:27 +0200
            The luminaries of duct-tape engineering [Sweeney and Torvald] (Was: The Mac Neo is a Budget Monster [GPU Channels]) Mild Shock <janburse@fastmail.fm> - 2026-08-11 16:51 +0200
  Re: Malicious Computer Architecture Aidan Kehoe <kehoea@parhasard.net> - 2026-08-03 19:51 +0100
    Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 00:22 +0800
      Re: Malicious Computer Architecture Richard Harnden <richard.nospam@gmail.invalid> - 2026-08-04 19:10 +0100
      Re: Malicious Computer Architecture Kaz Kylheku <046-301-5902@kylheku.com> - 2026-08-06 21:55 +0000
        Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-07 06:31 +0800
      Re: Malicious Computer Architecture Aidan Kehoe <kehoea@parhasard.net> - 2026-08-06 23:01 +0100
        Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-07 06:45 +0800
    Re: Malicious Computer Architecture Niocláisín Cóilín de Ghlostéir <thanks-to@Taf.com> - 2026-08-04 18:13 +0000
      Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 03:48 +0800
        Re: Malicious Computer Architecture Niocláisín Cóilín de Ghlostéir <thanks-to@Taf.com> - 2026-08-04 22:01 +0000
          Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 06:25 +0800
    GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-03 14:37 -0300
      Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Madhu <enometh@meer.net> - 2026-09-04 08:36 +0530
        Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-15 12:19 -0300
          Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Madhu <enometh@meer.net> - 2026-09-17 12:17 +0530
            Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-17 21:12 +0000
              Re: GNU Emacs native compiled functions Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-18 09:59 -0400
                Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-18 22:00 +0000
            Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-18 10:12 -0400
              Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-18 22:01 +0000
                Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) steve g <Sgonedes1977@gmail.com> - 2026-10-05 19:30 -0400
                Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 23:50 +0000
                Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) tfb <tfb@work.it.out> - 2026-10-06 05:11 +0000
                Re: GNU Emacs native compiled functions Aidan Kehoe <kehoea@parhasard.net> - 2026-10-06 08:30 +0100
              Re: GNU Emacs native compiled functions Aidan Kehoe <kehoea@parhasard.net> - 2026-09-19 14:47 +0100
                Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-19 21:58 +0000
                Re: GNU Emacs native compiled functions Aidan Kehoe <kehoea@parhasard.net> - 2026-09-19 23:24 +0100
                Re: GNU Emacs native compiled functions Paul Rubin <no.email@nospam.invalid> - 2026-09-19 17:23 -0700
                Re: GNU Emacs native compiled functions Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-20 03:05 -0400
                Re: GNU Emacs native compiled functions Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-22 18:20 +0000
                Re: GNU Emacs native compiled functions Aidan Kehoe <kehoea@parhasard.net> - 2026-09-20 22:20 +0100
                Re: GNU Emacs native compiled functions Paul Rubin <no.email@nospam.invalid> - 2026-09-20 16:18 -0700
                Re: GNU Emacs native compiled functions Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-21 12:56 -0400
                Re: GNU Emacs native compiled functions Madhu <enometh@meer.net> - 2026-09-22 12:22 +0530
                Re: GNU Emacs native compiled functions Paul Rubin <no.email@nospam.invalid> - 2026-09-22 10:15 -0700
                Re: GNU Emacs native compiled functions Madhu <enometh@meer.net> - 2026-09-23 07:33 +0530
                Re: GNU Emacs native compiled functions Aidan Kehoe <kehoea@parhasard.net> - 2026-09-23 07:22 +0100
                Re: GNU Emacs native compiled functions Paul Rubin <no.email@nospam.invalid> - 2026-09-24 03:06 -0700
                Re: GNU Emacs native compiled functions Lars Brinkhoff <lars.spam@nocrew.org> - 2026-09-26 04:45 +0000
                Re: GNU Emacs native compiled functions Madhu <enometh@meer.net> - 2026-09-27 16:24 +0530
                Re: GNU Emacs native compiled functions Paul Rubin <no.email@nospam.invalid> - 2026-09-27 15:02 -0700
                Re: GNU Emacs native compiled functions Madhu <enometh@meer.net> - 2026-09-28 10:53 +0530
                Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-05 19:47 -0400
                Re: GNU Emacs native compiled functions Anton Antimo <anton@safunu.org> - 2026-09-24 10:25 -0300
                Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-05 19:49 -0400
                Re: GNU Emacs native compiled functions Lars Brinkhoff <lars.spam@nocrew.org> - 2026-09-23 13:59 +0000
                Re: GNU Emacs native compiled functions Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-22 18:22 +0000
                Re: GNU Emacs native compiled functions tfb <tfb@work.it.out> - 2026-09-24 20:01 +0000
                Re: GNU Emacs native compiled functions Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-24 20:55 +0000
                Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-05 19:41 -0400
                Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-21 00:18 +0000
                Re: GNU Emacs native compiled functions antispam@fricas.org (Waldek Hebisch) - 2026-09-21 19:06 +0000
                Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-22 00:42 +0000
                Re: GNU Emacs native compiled functions Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-22 18:26 +0000
                Re: GNU Emacs native compiled functions antispam@fricas.org (Waldek Hebisch) - 2026-09-25 21:54 +0000
                Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-05 20:13 -0400
                Re: GNU Emacs native compiled functions Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-22 17:51 +0000
              Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-22 18:02 +0000
  A Case for Impurity: The Applied Pi Calculus (Re: Malicious Computer Architecture) Mild Shock <janburse@fastmail.fm> - 2026-08-04 14:58 +0200
    The Sandcastle of Paul Taraus Interactors (Re: A Case for Impurity: The Applied Pi Calculus) Mild Shock <janburse@fastmail.fm> - 2026-08-04 15:10 +0200

csiph-web